[Fedora-packaging] Re: BuildRoot

[Ralf Corsepius]

On Tue, 2006-07-25 at 12:42 +0200, Axel Thimm wrote:
> Hi,
> 
> On Tue, Jul 25, 2006 at 12:07:20PM +0200, Matthias Saou wrote:
> > Two quickies :
> > 
> > 1) The current "preferred" BuildRoot which executes "id -u" isn't
> > useful when used with mach or mock. I have nothing against it, I just
> > don't feel the need to use it... as it's "preferred", I should be able
> > to still use any BuildRoot value I want, right? I really simply prefer
> > the same, but without forking a useless "id -u" execution.
> > 
> > Yet another discussion about this here :
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188461
> > (nearly all my review requests change into debates regarding useless
> > details... I'm surprised that no one has yet criticized the non-aligned
> > header lines I use ;-))
> > 
> > If the "preferred" term is changed to "mandatory" in the guidelines, I
> > will abide, but continue thinking it's plain silly, and this brings us
> > to...
> 
> This was discussed a couple of days ago here, check the archives. FWIW
> I agree 110%.
> 
> Ralf argues that two users on a multiuser system building the same
> package with the same evr would get hurt (one would look the other's
> buildroot), which I consider an extreme corner case.
Absolutely not, consider this:

A team develops a piece of SW. A co-worker starts building an rpm, and
leaves at 3am after an rpmbuild had bombed out leaving %buildroot
behind. Next morning, you log in to the same machine, check out his
sources from svn/cvs and want to finish this work.
rpmbuild .. <boom>

> Furthermore currently building the same package for two archs (like
> kernel at i686 and kernel at i586) will hurt even more, which is not a
> corner case, so if we were to play it mega-safe we would had to add
> arch/epoch also to it.
Another example of a how views can vary: 
To me *this* is a very extreme case, because apart of very few package
almost nothing in FE is being build for several targets.

What's different about this situation, is this: If building under the
same account, this user at least is able to clean up %buildroot. In my
situation above, user2 can't clean up the remnants in %buildroot without
applying %_tmpdir tricks, "su" tricks or calling "the admin".

>  Better keep it small, simple and functional.
Better keep it consistent and conflict free.

I want "a mandatory buildroot" to achieve deterministic behavior,
comprising deterministic deficits and bugs.

Your and Thias' %buildroot regresses in comparison to the
"recommendation". It diverges from the "recommendation" and introduces
further non-deterministical behavior.

That's reason why I refuse to approve your packages.

> Anyway it looked like half the people here considered it an optional
> requirement (what "preferred" also really implied) and some would like
> to make it mandatory.
> 
> > 2) Why the heck is there still the need for BuildRoot to be defined in
> > each and every spec file we have!? Could we once and for all push a
> > sane default value into FC6 and start considering removing it once and
> > for all from all spec files by the time we reach FC10 or so?
> 
> Yes, that's the time scale, or maybe even FC110 :)
Well, nothing has happened for a decade, so ... my estimate is "near
infinity".

Ralf