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