https://bugzilla.redhat.com/show_bug.cgi?id=1064995 --- Comment #6 from Ralf Corsepius <rc040203@xxxxxxxxxx> --- (In reply to Paul Howarth from comment #5) > (In reply to Ralf Corsepius from comment #4) > > (In reply to Paul Howarth from comment #3) > > > > - %build section should likely use %{__perl} instead of perl > > > > > > The guidelines generally discourage the use of macros for commands except > > > where there's a need for the command path to be configurable, and cites > > > %{__python} as an example. In Fedora there have been parallel python2 and > > > python3 stacks so that might seem a reasonable example but Fedora has never > > > shipped more than one version of perl and so there's not really a need for > > > configurability here. So I prefer the tidier, shorter version. > > I have always been in favor of "%perl" and consider package which are using > > perl to be sloppily maintainedd, because it > > a) is an absolute path, which avoids picking up an arbitrary "perl" in > > $PATH, and thus improves deterministic builds > > I agree with this but FPC clearly don't care about this because the > guidelines discourage the use of macros for commands generally (e.g. > "%__cp", "%__mv"), in favour of unadorned commands. It's a bit pointless > doing this for some commands but not all. It's not a secret that I am in violent disagreement with FPC on this matter and consider enforcing perl in reviews greasy kiddy stuff. > > b) the possibility for fedora to ship another perl >> 0 (Perl6, Scls). > > Mechanisms for achieving these have yet to be determined,# Thanks to the widely spread mistake of using perl instead of %__perl this will be a pretty tough exercise. > and quite possibly > would not involve the %__perl macro. My view: %__perl points to the "system default perl", which today happens to be /usr/bin/perl, which happens to be perl5. If %__perl was used consistently, all of perl could be switched to a future perl version at once. Anyway, I do not see perl6 to arrive any time soon. > For instance, the dual python stacks in > Fedora are handled using separate %__python2 and %__python3 macros rather > than redefining %__python. Well, the situation on __python is really messed up, IMO. %__python should point to the system default python, while there is nothing wrong in having %__python2 and %__python3 to support packages with specific demands. Anyway, this is way off-topic for a review. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review