On Tue, 2006-07-25 at 12:42 +0200, Axel Thimm wrote:
On Tue, Jul 25, 2006 at 12:07:20PM +0200, Matthias Saou wrote:
> Two quickies :
> 1) The current "preferred" BuildRoot which executes "id -u"
> 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
> 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 :
> (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
> will abide, but continue thinking it's plain silly, and this brings us
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
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@i686 and kernel@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
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