Perhaps this would be a good opportunity to ask everyone packaging CPAN modules to at least look at the provides string generated by pacpan. It cross-references all names with their associated source files to generate a comprehensive list.

I've moved it into [community] now, so it's be easily accessible. I'll remove the AUR package once the repos have synchronized.

Cedric Staniewski wrote:

Thanks. I thought about that again and am curious if there is a name convention for CPAN source files. It might make sense to set pkgname to 'perl-' the name of the source file (lowercase and without version and suffix, of course) by default in pacpan generated PKGBUILDs, even though libwww is an exception again.

They should definitely look at the PKGBUILD before uploading them. I have seen provide arrays with items like 'modulename=undef' and there is a new license introduced by these PKGBUILDs called '~'. But that is the drawback of such tools; they make it so easy to generate PKGBUILDs and thus you get quantity but often less quality.

There is a naming convention but the problem is that several modules on CPAN use the same source and install the same component modules. Pacpan generates a comprehensive "provides" list by cross-referencing all the names and sources and thus includes all alternative names which rely on the same source files. The user has to select the "main" module though and include the comprehensive provides string to avoid overlap, which is why I've sent the full "provides" array for Bundle::LWP to the perl-libwww packager (which should be named perl-bundle-lwp). The inclusion of "undef" was due to a bug in pacpan where I had used a simplified version check, which I've now fixed. Even so, you're right that pacpan is incapable of always producing perfect PKGBUILDs and it was never intended to be used without inspection of the results. It relies on correct and complete meta information on CPAN (some module authors don't bother) and a standard build function. In most cases it works as expected and in others it usuallyl provides a good starting point, but sometimes it's assumptions are horribly wrong and it fails miserably. Regards, Xyne

Daenyth Blank wrote:

Personally I've always found the current behavior very annoying. Why not just generate the arch standard names for the depends array and let the packager work it out if that isn't correct? Defaulting to the standard seems better than defaulting to print everything, most of which gets removed by hand. It's the single biggest peeve I have with pacpan. (Not to say that I don't find it useful.)

I don't understand what you mean. Pacpan is quite good at detecting dependencies. It checks if necessary CPAN modules are already installed and if they are it determines which pacman package they belong to. If the dependency isn't already installed, it checks pacman's database for a package which provides the dependency. The only way it produces a dependency list which is superfluous is if either the metadata on CPAN is incorrect, which is the module author's fault, or if existing packages fail to correctly list all of the packages/modules which they provide, which is then the packager's fault. The only case in which this might be an issue would be when recursively building packages to satisfy dependencies. It can't know a priori if two packages specified in CPAN's metadata are actually provided by the same package if that package doesn't yet exist. That's not really an issue though because once that package exists, it will provide both of the required packages and thus satisfy the dependencies. What exactly are you removing by hand? If you're actually talking about the provides array, you'll be happy to learn that pacpan no longer includes standard CPAN names in that array. I had originally included them because I had seen other perl packages which did so and I didn't think it would hurt to be thorough. Sorry if this doesn't address your issue, but in the context of the "depends array" I really don't know what you mean by "defaulting to print everything". Regards, Xyne

...

...

=> perl-http-headers http://aur.archlinux.org/packages.php?ID=25730

=> perl-http-request http://aur.archlinux.org/packages.php?ID=25736

=> perl-http-response http://aur.archlinux.org/packages.php?ID=25735

=> perl-lwp-simple http://aur.archlinux.org/packages.php?ID=27566

=> perl-lwp-useragent http://aur.archlinux.org/packages.php?ID=25734

perl-libwww has been updated so I've removed these from the AUR.