[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

perl module packages: why do they exist?



[APH: I'm CC'ing the CPAN.pm maintainer here, since I though Mssr 
 König might be interested in the issues we're having.  I'm going to 
 recap that discussion, if everyone will tolerate me a little.  Note
 also I use CPAN.pm to refer to the Perl module, and CPAN to refer to
 the actual archive.  Andreas, I'm not sure if your interested or
 even the right party to talk to, but feel free to forward this to
 anyone who might be interested or just trash this message.]

Andreas, this is part of discussion we're having on the Debian developer's
list concerning what I consider some conflicts existing between
the Perl module maintainence subsystem, CPAN.pm, and Debian's
package maintanance system.  (BTW, Debian is a free linux distribution, 
and is widely hailed as having the premier Unix s/w packaging system.)
I raised this thread, asking why Debian developers bothered making 
packages out of CPAN modules, when Perl already had dependancy tracking 
and update featuers.  Said developers pointed out some problems
they have with CPAN.pm and it's operations.  I guess the major reasons we 
need a Perl module version control mechnaism are the following:

* no good way to sync Perl module version numbers w/ Debian version 
  tracking (see below)
* quality control for Perl modules; put them thru testing before release

[You (rdm@test.legislate.com)]
>Raul Miller <rdm@test.legislate.com> wrote:
>> >About two months ago, I upgraded a CPAN bundle on a production server.
>> >Two interesting things happened:
>> >
>> >(1) perl itself got upgraded, and
>> >(2) wais got upgraded.
> 
>Adam P. Harris <apharris@onshore.com> wrote:
>> Huh??? Perl itself?  I don't think this is possible.
>
>Take a look at TIMB/perl5.004_04.tar.gz

Wow.  Guess I'm a little out of it.

>It is automatically brought in when you install something in 
>CPAN that requires a more recent perl version that what you
>have.

There should be a flag to disable this behavior!

>Of course, you can bail out of the install at that point, but that's not
>the issue here.
>
>In my opinion, once we've evolved a good cpan->debian packager, we
>should integrate it with the CPAN module so that it uses this mechanism
>to build, test and install cpan modules.  Presumably, it should also
>archive the installed package somewhere (at least as an option), and
>manage minor revision numbers automatically.

I completely agree.  I suppose this is a ExtUtils issue?  So as I under
stand you, say, the Makefile produced by `perl Makefile.pl' would, say, 
have a 'debian-pkg' rule or something.  Right?

>Further, it's going to be essential that we get dependencies *right*
>for the part of the system which can be managed via CPAN. This is going
>to be tricky -- since dependency information in cpan is embedded in
>makefile rules, we'll probably have to implement a shared database so
>that as people use the system we accumulate such information. [This
>might also be a fertile ground for people to get together when thrashing
>out problems with fringe packages.]

Can't you pull out module version numbers from the modules themselves?  I 
think this is what ExtUtils does when it makes `Makefile'.

I think the way to do this is to add some state to install Perl modules.
Modules installed with dpkg should be distinguishable from user installed
(say using CPAN.pm) modules.  Actually, no need to add state when it's
already there; user-installed modules are installed in 
/usr/local/lib/perl5/site_perl.  The next step would be to try to hack
CPAN.pm to disallow updating (or overriding by having copies in 
/usr/local/lib/ perl5) files which _must_ by Debian policy be under package
management control (i.e., /usr/lib/perl5). 

The corollary to this is that users who insist on installing a packaged
and installed module right from CPAN must first remove the package (?).
This would disallow installation of packages that rely on that Perl
module, which is probably desired behavior.  Debian hackers could always 
override the dependancies.

Manoj, I guess I just now have come around to where you were all along? ;)

.....A. P. Harris...apharris@onShore.com...<URL:http://www.onShore.com/>

Attachment: pgpvU3DT013Hp.pgp
Description: PGP signature


Reply to: