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@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 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 -- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging