On Mon, Jul 08, 2013 at 02:57:16PM +0200, Ralf Corsepius wrote:
> 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.
Yes, that happens when you don't explicitly list them.
> 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.
Why is "everything" quoted when I actually was talking about
everything? The "single point of time" you're referring to
is a stable package state and the same applies to Version,
for example. That too changes when the package is updated.
I agree there might be bloat if the packager is careless and
doesn't maintain the package properly but that's not really
different from the current situation when some people just add
BRs if the build fails and that's all.
> >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".
This is true. However the same argument could be used for any
invoked tool, such as 'mv', 'rm' et al., while current Packaging
Guidelines discourage using macros in those situations (and
we're not in the same situation as python).
> >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.
Nope, this was mainly about using $() instead of ``.
> >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.
I didn't say anything about removing Module::Build from Fedora.
Our guidelines instruct packagers to prefer Module::Build over
ExtUtils::MakeMaker, which conflicts with what upstream recommends.
The only that needs changing is the wording.
> >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
The last one is a point like any other; a suggestion for possible
future guidelines.
Petr
Attachment:
pgppYblZdrzN8.pgp
Description: PGP signature
-- 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
