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.
IMO, that's a completely different topic, which is beyond the scope of this threat.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?
Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/perl-devel
