Re: Don't update to current cooker

On Jan 24, 2012, at 8:35 AM, Denis Silakov wrote:

> On 01/24/2012 05:00 PM, Jeffrey Johnson wrote:
>> I can "partially" agree.
>> 

Well lets attempt "fully agree".

The process workflow for cooker is essentially this:

    SRPMS -> BUILDSYSTEM -> MIRRORS -> USERS
                    A                                B                     C

I have make the transitions with {A,B,C} because that is the logical
place to add better automation to achieve higher quality.

Your "smarter build system" is at point B and "smarter" implies
implementations to achieve higher quality.

My original proposal was at point C, and slowing down the
process flow implicitly assuming that manual/automated
tools could be applied yo improve quality. Doing
daily (rather than weekly/monthly) releases to USERS
leads to quite predictable breakage, and there aren't enough
hours in a day to attempt better QA at point C.

I will point out that Per Oyvind's rpmlint work to improve
the input SRPM recipes is at point A, which both better
(because its earlier) and harder (because fixes at point
A aren't so easily automated and require detection
at B by rpmlint in order to achieve better recipes at A
through manual editing).

Can we fully agree on the above?

>> 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.
> I can also "partially agree".
> 
> Breaks in cooker happen quite often, they are just not as big as the ones caused by Perl update. Some big updates can require more manual work and for them a special process can make sense, indeed. But I believe that such updates are not numerous/frequent.
> 

I will never question your "belief" other than to point out that reality is
sometimes different.

> Numerous breaks arise, for example, when a package update requires dependent packages to be rebuilt (this is the case for perl update, as well). Currently it's a common situation when nobody cares about rebuilding them until facing problems when updating from cooker. This is the problem the build system can help to solve, making cooker much more consistent without much efforts from maintainers side.
> 

Note that there is an RFE to "automated rebuild of dependent packages" (paraphrased) implied
in your statement that is quite important.

Most build systems like OBS and koji+mock do not have that
fully automated yet (though the need is obvious, its often
achieved/scheduled by manual submissions or by "make world" events).

hth

73 de Jeff