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 nando@xxxxxxxxxxxxxxxxxx 2006-05-15 12:54 EST ------- (In reply to comment #8) > (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. Arghhh, sorry, just a misunderstanding on my part. For some reason I though that the "regression" you were mentioning was to use %{__rm}, not to take it out. Sorry. We are in agreement about the macros. -- 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