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(a)city-fan.org 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.