Perl packaging guidelines
Petr Šabata
contyk at redhat.com
Mon Aug 5 11:56:53 UTC 2013
On Sun, Aug 04, 2013 at 11:58:46AM +0200, Emmanuel Seyman wrote:
> * Petr Šabata [08/07/2013 14:25] :
> > Second, the %{__perl} macro.
> > What are the benefits of using this (subjectively) ugly macro
> > compared to simple 'perl'? The only case in which I find it
> > useful is when we actually require the absolute path, e.g. in
> > shebang corrections.
>
> The two main cases I see are:
>
> a) future proofing
>
> One day, perl may move to another location than /usr/bin/perl (yes, I know it's
> unlikely). On that day, you can change one macro (by modifying %{__perl}) or
> change all your spec files. I know which one I prefer.
>
> b) brokeness proofing
>
> While simple 'perl' works in a mock/koji context, our sources rpms got rebuilt
> in other build-systems, not all of them as solid as mock/koji. I can't
> guarantee that plain 'perl' will work the same way that %{__perl} does in those
> build-systems.
This could only fail if perl isn't in the PATH (hard to imagine
unless it's a bug). In all other cases, it should work no
matter where the binary is located.
The only situation in which this macro would be useful is
migration to a completely new perl, like Ralf said. But since
perl6 is a completely different language at this point and
not aiming at replacing perl5, I don't really see a point in
keeping this.
Anyhow, this is mostly about taste and I'm fine with either.
Petr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 230 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/perl-devel/attachments/20130805/30b1f086/attachment.sig>
More information about the perl-devel
mailing list