Re: Don't update to current cooker

On Jan 24, 2012, at 10:21 AM, Jeffrey Johnson wrote:

> 
> 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)
> 

Permit me to translate this from "jbjerish" because these
are items of importance for the RPM -> ROSA (and other( ROADMAP).

The RPM (actually rpm build) problem that was asked a couple years back was this:
	How can a user known how long a build is going to take?

The obvious design answer is
	Use a progress bar!
The problem there is that stdout/stderr are already in use by rpm build,
and a progress bar isn't all that useful when rpm build is being
invoked by ABF or other build systems: some other channel
is needed.

There is the further problem that a progress bar is typically scaled
to 0 -> 100, but the total time isn't known in advance.

In a naive world of "progress bar" displays, this is typically
dealt with using ASCII art for spinning wheels, or a "Knight Rider"
display that just goes back and forth to indicate forward progress
(but without attempting to display the ETA).

This led to a week-long bikeshed discussion (bikeshed discussions
are important too) @rpm5.org about the relative merits of
spinning wheels vs "Knight Rider" displays, neither of which
solves the fundamental issues of
	1) how should the total time be captured into metadata
	2) how should progress be handed from rpmbuild -> build system

After a week of listening, I chose this insane implementation:
	1) setproctitle(3) can change argv[0]. Sadly there are only 16b (iirc) available
	2) top(1) will display argv[0] of a running rpm buildprocess.
	3) the /proc/* info is accessible by build systems

So -- if enabled -- one can literally see rpmbuild "progress" by
running top(1).

But the 16b available aren't sufficient to convert anything important,
and the problems in need of solving are:
	1) capture total build time into a *.src.rpm (and perhaps as *.spec tag)
	2) choose an intelligent way for rpm build to deliver the dynamic
	state to other tools (like ABF) that might well wish details about what
	rpm build is actually doing.

Hint: These days I have far more effective solutions at hand than
the setproctitle(3) "parlor trick". Namely
	The mongo-c-driver is carried in RPM sources, "batteries included".

Apologies for the "jbjerish" confusion: I hope the translation helps,
headed for a RPM blueprint whenever there is a perceived need.

hth

73 de Jeff