FS#18113 - [pacpan] request to officially recommend use of Pacpan for CPAN packaging

Attached to Project: Pacman
Opened by Xyne (Xyne) - Monday, 01 February 2010, 22:33 GMT
Last edited by Aaron Griffin (phrakture) - Wednesday, 17 March 2010, 22:10 GMT
Task Type Feature Request
Category Scripts & Tools
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version 3.3.3
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

http://xyne.archlinux.ca/info/pacpan
http://bbs.archlinux.org/viewtopic.php?id=89752

I've completely rewritten pacpan and I feel that it is not mature enough to be officially recommended as a tool for packaging CPAN packages for Pacman. I would like to request support from the devs to make this an official policy. I will then update the Perl Packaging Guidelines in the wiki accordingly.

Please review the info page and the forum thread posted above for full information and output examples. I'll will only give a brief overview here:

Pacpan can match any module to it's distribution on CPAN and create a comprehensive PKGBUILD with fully populated depends, makedepends, optdepends and provides arrays. This will improve the ability of pacman to resolve dependencies for all CPAN packages and it will provide a consistency for all such packages. Each module maps to its distribution and each distribution maps to a standard pacman package.

There is also a function which inspects installed Perl packages and prints out a report which estimates their adherence to the naming guidelines and suggests name changes if they do not adhere. It can also generate a comprehensive "provides" array through direct detection of the files owned by the package. This will let packager's validate their provides arrays. Non-packages may also choose to update the provides array in the local database while waiting for packagers to update the packages. This will allows regular uses to satisfy dependencies as they wait.

As I said, this is just a brief summary. I would also like to add that the code is still fresh but I believe the functionality is already quite dependable

This will not be a fully automatic solution for all packages but it gives packagers a very good starting point and only a few tweaks will be requires at most in most cases.

If this proves to be reliable, I may also consider populating the AUR with CPAN PKGBUILDs via scripts the same way that the Arch Haskell teams does.
This task depends upon

Closed by  Aaron Griffin (phrakture)
Wednesday, 17 March 2010, 22:10 GMT
Reason for closing:  Won't implement
Additional comments about closing:  The dev team did give serious consideration and actual criticism here:

http://mailman.archlinux.org/pipermail/a rch-dev-public/2010-February/015320.html

Original author no longer interested in proposal
Comment by Caleb Cushing (xenoterracide) - Wednesday, 17 March 2010, 20:56 GMT
I would not like to see this happen. http://aur.archlinux.org/packages.php?SeB=m&L=2&K=xenoterracide I'm pretty sure I maintain more CPAN packages than ANYONE (250+ currently and growing) right now. And many of those have high profiles in the perl community (Moose, Catalyst, DBIC). The official recommendation of the perl community is to use tools available in CPAN. I'm using CPANPLUS::Dist::Arch it is the only tool that is available on CPAN. pacpan may have a few features currently not in C::D::A but that's being worked on.
Comment by Xyne (Xyne) - Wednesday, 17 March 2010, 21:47 GMT
So we can change the recommendation to use that then. I find it surprising that nearly all opposition to this idea has been without constructive criticism or proposals of alternatives. Rather than simply point out that pacpan is not on CPAN and therefore not recommended, why not make a suggestions instead, such as moving it to CPAN, merging it with C::D::A, etc.

My main goal is not to have my own tools officially recommended but rather to have a sane and robust way to build packages from CPAN that's officially endorsed to ensure the greatest package compatibility on Arch (and any other distro which uses pacman).

Anyway, I'm done with this. Requesting closure.
Comment by Caleb Cushing (xenoterracide) - Wednesday, 17 March 2010, 22:08 GMT
Merging them is something to be taken up between authors. I'm not opposed to being put on CPAN but the fact that it doesn't work within existing CPAN mindset... that's also something up to the author. I'm simply stating that AS IS pacpan wouldn't be necessarily recommended by the perl community, as to them it really doesn't exist, and if people go on #perl and ask... well it just creates conflicts. I'd be happy to work with you to try to make your goal of one tool to do this though. I can't speak for Juster... but I'm sure he would too.

Loading...