Perl packaging guidelines

[Emmanuel Seyman]

* 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.

> Third, the MODULE_COMPAT macro.

See above.

> Fourth, ExtUtils::MakeMaker vs Module::Build.
> Module::Build is currently being deprecated and removed from
> core, ExtUtils::MakeMaker becoming, once again, the preferred
> way.  Our guidelines should be updated to reflect that.

+1

> And fifth, installation paths.
> I suppose the guidelines should explicitly state the vendor
> paths should be used.

+1

Emmanuel