Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: qjackctl - Qt based JACK control application https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191239 ------- Additional Comments From paul@xxxxxxxxxxxx 2006-05-15 06:45 EST ------- (In reply to comment #6) > I agree and that's why I use, when possible, built-in macros. > > [I thought it was policy.] It's not policy, unless the packaging guidelines have changed since I last read them. > My take on this: if the results of running a build script depend on overriding a > basic core unix command by the script builder then I'd label that a bug in the > build script. While your example for rm sounds reasonable, it is not in the > context of executing a build script which, I think, cannot/should not be > interactive. Using the macro would actually expose (IMHO) a bug. I'm sure other > more applicable examples could be put forward, of course... I don't understand what you're getting at here. The example I gave was that someone rebuilding a package had a local "rm" script, earlier in their PATH than /bin/rm, that prompted for confirmation. If this person rebuilt a package that used plain "rm", the build would become "interactive" (which is bad), but if they rebuilt a package that used "%{__rm}" instead, the build would be non-interactive as it's supposed to be (since %{__rm} would expand to /bin/rm and hence their local rm script wouldn't be used). Using the macro is hence an advantage. (In reply to comment #7) > My preference is to only use macros if there's a solid gain to be had. As in, > its something that's expected to change (versions) or it handles something ugly > for you (%configure). I don't see any real gain in using macros such as > %{_make}. I think reproducability of builds is a solid gain. > And most of all, the spec templates do not use these macros, which > implies to me they should not be used. Or perhaps the templates should be updated? > It would be nice to have an explicit policy up on the wiki for this, even if > that policy is "Use whatever, just be consistent", much like the %{buildroot} vs > $RPM_BUILD_ROOT policy. +1 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review