Perl packaging guidelines: request for a new official policy

Question

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)

Answer 1

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.