[arch-dev-public] Fwd: Perl packaging guidelines.

Aaron Griffin aaronmgriffin at gmail.com
Sat Feb 6 19:56:20 EST 2010


---------- Forwarded message ----------
From: Xyne <xyne at archlinux.ca>
Date: Sat, Feb 6, 2010 at 2:32 PM
Subject: [arch-dev-public] Fwd: Perl packaging guidelines.
To: aaron at archlinux.org

Hi,

Sorry that I'm posting outside of the thread. I just subscribed to the
list so I didn't have the previous messages to reply to.

> I'm not sure about the idea.

> From what I understand, Perl comes in CPAN "distributions", which
> contain some modules.  We take a "distribution" and make a package.
> This script fills out a provides array with all modules that are part
> of the package and makes the dependencies be these modules.  That may
> be technically more correct, but the sacrifice is a lot of complexity
> that I am not sure is really needed.

> How often do modules swap from one "distribution" to another?
> Robustness to that is the only advantage I see here.  I might be
> missing something...

I didn't understand what you meant by "makes the dependencies be these
modules".

You're right that pacpan fills out the provides array with the modules
contained in a distribution and that modules do not jump between
distros very often. I considered that as well, but that is not a rule
and distributions are occasionally split and merged. This would prevent
breakage in such cases.*

The real advantage of this is that the metadata provided by CPAN
distributions in META.yml files often specify specific modules, not
distributions. The upstream packagers and CPAN itself obviously think
that this is the right way to do it, probably for the aforementioned
possibility of splits and mergers.

Including the provides, depends, makedepends and optdepends (with
occasional tweaks) produced by pacpan is hardly difficult for the
packager and that is exactly what these arrays are for. It thus
guarantees that pacman can handle dependencies regardless of what
happens upstream and it follows CPAN's packaging standards, which is
thus in line with Arch's goal of being as vanilla as possible.

Coincidentally, the Arch Haskell group recently decided to make it
official policy to explicit list provides and depends in all Haskell
PKGBUILDs because they've found that this is a better solution for
long-term dependency handling.

Considering how this simply uses existing pacman functionality, I don't
really understand your argument about complexity either. All the
packager has to do "pacpan --get-pkgbuilds <foo>" and check the output,
then, after installation, optionally run "pacpan --check-local" to
double-check. This presents no added complexity to pacman itself. This
is far simple than not specify explicit dependencies and dealing with
breakage when it occurs. The latter approach is lazy and short-sighted
in my opinion, especially in light of how trivial it would be to
prevent.

Aside from the comprehensive arrays, pacpan will also recommend
standard names for modules which do not have them, and this makes
finding packages easier if applied to all packages in the official
repos as well as the AUR and elsewhere. It prevents conflicting and/or
redundant packages which package the same distribution under different
names, it turns up the correct package when searching for modules, etc.



Having a tool which provides a standardize starting point for all CPAN
modules should be a good thing and I think it could do for Perl packages
what cabal2arch has done for Haskell packages.



* Just to show that this actually does happen, this is from my
 pacman.log:

The following official packages can be removed since the modules are
now included in the standard perl library:
 perl-archive-tar  perl-compress-raw-zlib  perl-compress-zlib
 perl-extutils-cbuilder  perl-io-compress-base  perl-io-compress-zlib
 perl-io-zlib  perl-module-pluggable  perl-pod-escapes  perl-pod-simple
 perl-module-build  perl-version

These community packages are also included in the standard perl library:
 perl-archive-extract  perl-cpanplus  perl-digest-sha  perl-file-fetch
 perl-extutils-parsexs  perl-ipc-cmd  perl-locale-maketext-simple
 perl-log-message  perl-log-message-simple  perl-module-corelist
 perl-module-load  perl-module-load-conditional  perl-module-loaded
 perl-module-pluggable  perl-object-accessor  perl-params-check
 perl-term-ui  perl-time-piece

As  you can see, things do change and having explicit dependencies will
only prevent breakage.


Regards,
Xyne


More information about the arch-dev-public mailing list