Re: Don't update to current cooker

On Jan 24, 2012, at 3:51 AM, Denis Silakov wrote:

> On 01/20/2012 01:21 AM, Jeffrey Johnson wrote:
>> (aside)
>> But how SHOULD large upgrades like perl/ruby be handled
>> in "real time" when Cooker breaks not for any important
>> reasons but because a large upgrade is in process?
>> 
>> libpng 1.5 was another example: weeks to sort out a
>> complex upgrade that (imho) need not have been
>> distributed until complete?
>> 
>> The cooker/rawhide model needs to change somehow.
>> 
>> One approach would be to "bundle" large upgrades
>> until ready. The problem there is that if two large
>> upgrades are "isolated" then when each is released
>> there will still be incompatibilities.
>> 
>> Another approach would be to delay cooker updates
>> to a weekly (instead of daily) time scale in order to
>> permit time to do some simple QA (or perhaps even compose
>> a minimal image like Franck is offering to do monthly).
>> A longer time scale also allows users to judge when
>> _NOT_ to upgrade if, say, the weekly release was Friday
>> and the weekend were used to clean up issues. (Friday
>> may or may not be the right day: but a weekly schedule
>> might allow some time so that end-of-week was higher
>> quality than beginning-of-week updates).
>> 
>> There's *got* to be a better process flow here imho: needless
>> (and endless) breakage is hard to keep up with.
> Such problems can be partially avoided by using smarter build system which can automatically track at least dependency breakage, rebuild dependent packages, etc. For example, OBS (opensuse build system) has some possibilities of such kind. ABF is also supposed to provide some similar services.
> 

I can "partially" agree.

The argument for a "smarter build system" however confuses the build tools used
with the build process task.

Current build systems like OBS and ABF (and koji+mock) use a depsolver.
The depsolver under build systems would have been "partially" broken by the
recent libpng1.5 upgrade just as effectively as the depsolver used to
upgrade clients was. For ABF, its is in fact the same URPMI depsolver
in use with identical (and broken) libpng1.5 assertions.

I do say "partially" because the chroot's constructed for builds
are usually constructed differently, without graphics, and so
the depsolver would be more immune to libpng1.5 breakage
than the depsolver used to update desktops. But that is merely
a "partial" accident of the usage case, not anything directly solved
by "smarter build systems".

Its the process of attempting to use just built packages in a process eedback loop
in a build system, or through repository mirrors delivering to users, with
minimal (and inadequate) QA that is breaking,

And its the process, not the tools, that has to be redesigned somehow,
or the "smarter build systems" will break just as often as cooker breaks.

hth

73 de Jeff


> -- 
> Denis Silakov, ROSA Laboratory.
> www.rosalab.ru
>