Re: Don't update to current cooker

On Jan 24, 2012, at 10:02 AM, Denis Silakov wrote:

>>> 
>>> 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.
>> 
> Surely :) But we don't seem to have reliable statistics for well-reasoned discussion.
> 

Well you do have some reliable statistics, more needs to be done (see below).

The size of a package is measured and saved reliably in a *.src.rpm.

The results of the %prep/%build/%install/%clean exit codes are collected
during build. I forget whether I've put the results into *.src.rpm headers yet,
its merely one call to headerPut() somewhere.

In order to display build progress bars (through setproctitle(3), 16b
or progress bar buried into /proc/* was merely a parlor trick when
@rpm5.org drifted off into various displays of progress like spinning
wheels and "Knight Rider" displays and I was frustrated with the discussion)
implicitly assumes
	1) there is a stop watch on the build process
	2) the total time is known a prior it so that 0 -> 100% normalization is possible
There are some minor scaling issues that need to be solved for a
measured build time to be distributed "portably": wall clock time depends
implicitly on CPU Hz etc)

And rusage(3) to capture memory and diskspace (and other) metrics isn't
hard coding. What is hard is that every additional piece of information
added to *.rpm headers triggers a
	Bloat! Bloat! Bloat! Bloat!
fire drill discussion (so I choose my RPM battles carefully and wisely).

There is no build system I am aware of that has a scheduler that
fully integrates process metrics with queues. The more typical
(and perhaps better) problem that is always implemented is "clout"
	This build is more important than other builds and so goes first.

rpm build is wonderfully positioned to collect whatever reliable
statistics you wish to see. Here's another (and wilder) suggestion
for a metric:
	Compression algorithms remove redundancy and increase residual entropy.
	Different compressors are better/worse dependent on residual entropy.
rpm build is very well positioned to calculate residual entropy reliably
both per-package and per-file and heuristics can then be devised
to use the most effective compression.

Instead what is being done is this:
	1) Compress tar balls using bzip2 to minimize build system diskspace,
	2) Compress *.src.rpm payloads to minimize download bandwidth.

What is silly is that 1) and 2) have conflicting goals and two compressions
is more cpu costly than 1).

hth

73 de Jeff


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