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(a)ccrma.stanford.edu 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.