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