Perl packaging guidelines: request for a new official policy

Xyne · 2010-01-28 11:17:31

feature request about this here: http://bugs.archlinux.org/task/18113

*edit*

Ok, the new version of pacpan is out: http://xyne.archlinux.ca/info/pacpan
It's only in my repo for now. I'll move this version to the AUR after some feedback.

After some initial debugging (if necessary), I would like to request that the official Perl packaging guidelines be changed to recommend using pacpan as a tool to aid packaging CPAN packages. In many cases it will provide a fully working PKGBUILD by default and in those cases when it doesn't, the provided PKGBUILD will be a very good starting point. It can also be used for comparison to existing PKGBUILDs.

Packagers will find the following functions useful (please see the info page for some output examples):

pacpan --get-pkgbuilds [pkgs]

This will print out default PKGBUILDs for the specified packages. Packages may be specified with the standard pacman package names (e.g. perl-foo-bar) or with the CPAN names (e.g. Foo-Bar for a distribution, Foo::Bar for a module). Pacpan will map modules to their distributions uniquely and thus prevent package conflicts when attempting to package different modules which are in the same distrbution.

It will also provide a comprehensive provides array which will ensure dependency resolution when dealing with dependencies specified in META.yml on CPAN.

Pacpan is also able to detect depends, makedepends and optdepends for CPAN packages.

Of course this depends on the presence and correctness of the META.yml file on CPAN, but this is present for (nearly?) all active distributions.

pacpan --check-local

This will inspect local perl packages and determine if local CPAN packages are named according to the packaging guidelines. It will also determine which modules a package provided by directly matching the files owned by the package according to pacman against the modules provided by those files, including version numbers where available. This will show packagers mistakes in the package and suggest changes to correct them. There is also a function for regular users to update the provides array of perl packages in the local database to ensure dependency resolution while waiting for packagers to correct their PKGBUILDs.

Last edited by Xyne (2010-02-01 22:35:47)

tomk · 2010-01-28 12:58:07

Put this is a feature request, Xyne - the devs generally don't come here very much.

Xyne · 2010-01-28 19:06:50

I know, I wanted to try to get a general discussion going though because this affects all Perl packages. The forum is the best place for a common discussion that involves regular users as well.

I'll finish the rewrite and then I'll post a feature request.

juster · 2010-01-31 07:33:09

I am the author of CPANPLUS::Dist::Arch another automated "packager" for CPAN perl modules. I have always thought that CPAN distributions map well to the idea of pacman packages. Distribution <=> Package. They are the container and each dist/package can contain many modules (files).

I do not understand the need for your provides= line to list modules and their versions. What is the point? Why is this needed? It makes things more complicated than they need be. Why allow people to add module names to their package dependencies? This seems to me like having people use depends=('convert') instead of using depends=('imagemagick'). (convert is one of many programs included in the imagemagick package for those who havent used it.)

Xyne wrote:

For the sake of consistency, I request that the distribution name returned by pacpan (once rewritten) be used for all CPAN packages.

I agree using only the module's distribution name in the package is a good idea. I think it's better just to disregard the idea of modules and convert them to their distributions for the perl packaging policy.

Xyne · 2010-01-31 10:17:53

The reason to include modules in the provides array is to enable finer tuning of dependencies. If the modules within a distribution ever change, there would be no need to change the depends array of all packages which had specified that distribution instead of the modules that they actually depend on. It also makes searching easier as someone who is looking for the functionality of a particular module will be able to find it via a pacman search.

If that is really an issue, then it would be trivial to remove the provides from the PKGBUILDs that the code generates. If we could strictly enforce the packaging guidelines in the official repos and the AUR then I suppose it might make sense to ignore modules completely, but I don't see how it hurts to list them in the provides array.

With the current code that I have, I think I have full module-to-distribution resolution and all PKGBUILDs generated by the code for a requested package or module map to the corresponding distribution. The pacpan rewrite is complete and I'm working on plugging the backend into bauerbill right now to handle dependency resolution, installation and makedeps removal. I hope to release the code soon (maybe today, depending on how productive I am), at which point we can really get this discussion going with a feature request on the bug tracker.

Xyne · 2010-02-01 22:15:26

Ok, it's out, take a look.

Check out bauerbill too, which now uses the same backend to build CPAN packages.

Arch Linux

#1 2010-01-28 11:17:31

Perl packaging guidelines: request for a new official policy

#2 2010-01-28 12:58:07

Re: Perl packaging guidelines: request for a new official policy

#3 2010-01-28 19:06:50

Re: Perl packaging guidelines: request for a new official policy

#4 2010-01-31 07:33:09

Re: Perl packaging guidelines: request for a new official policy

#5 2010-01-31 10:17:53

Re: Perl packaging guidelines: request for a new official policy

#6 2010-02-01 22:15:26

Re: Perl packaging guidelines: request for a new official policy

Board footer