Perl packaging guidelines

[Ralf Corsepius]

On 07/08/2013 02:25 PM, Petr Šabata wrote:
> Dear list,
>
> Following the recent thread on the Packaging list [1], and
> since those questions arise fairly often during reviews, I
> think it'd be a good idea to discuss some possible updates to
> our packaging guidelines.
>
> We all have different opinions on Perl packaging but I'd like to
> find some common ground and set some standard how to do things
> to unify our style.

  I think there is only one group of perl packagers whose opinion is 
different from the rest ;)

> First, the dependencies, both build- and run-time.
> Personally I like to list every module which is actually used
> since this means the package only fails to build when
> there's an actual issue, not just a change in the dependency
> chain.

This sentence is not precisely enough formulated to be able to comment.


> I also think not listing some modules only because
> it's unlikely they'd get removed from core makes packaging
> harder and more confusing, rather than the opposite.
I vehemently disagree.

When perl modules move away, they break building - I.e. these can easily 
be re-added at any time, when necessary.

Conversely, adding "everything", only meas to reflect the dependency 
state which was valid at one single point in time.
  As the work-load and effect related to tracking theses is significant, 
pn the longer run, these dependencies state will gradually and silently 
diverge from the actual dependencies. I.e. all this does is to add 
redundency and dependency bloat.

=> lower packaging quality.


> Second, the %{__perl} macro.
> What are the benefits of using this (subjectively) ugly macro
> compared to simple 'perl'?
The benefits will show when
a) the path to perl should change.
b) the name of the perl program will change.

In both cases, all packages using a hard coded /usr/bin/perl will break.

Plain "perl" contradicts the principles of "deterministic builds":
Simply install a script named "perl" somewhere on your $PATH and run 
"rpmbuild" with a spec using "plain perl".

> Third, the MODULE_COMPAT macro.
> Currently our guidelines enforce the following form:
> perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version))
> I propose the following forms are also accepted (the latter
> two in case we accept simple 'perl' too):
> perl(:MODULE_COMPAT_%(eval "$(%{__perl} -V:version)"; echo $version))
> perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
> perl(:MODULE_COMPAT_%(eval "$(perl -V:version)"; echo $version))
That's topic 2) from your list.

> 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.
Sigh, you can not remove any perl module from Fedora, which is still in use.

I.e. no matter how much you want to remove it, no matter how much 
upstream wants to see it removed/deprecated, these modules need to stay 
in Fedora at least until no package in Fedora uses it.

> And fifth, installation paths.
> I suppose the guidelines should explicitly state the vendor
> paths should be used.
>
>
> That's all I can think of now.  Please, do share your views.
> Also, what would you like to change or improve?
IMO, that's a completely different topic, which is beyond the scope of 
this threat.

Ralf