Perl packages, CPAN, locally installed .pm files
Apologies, this is a long mail. If you're not interested in our perl
package, skip it now...
Not so long ago, I posted a report of this problem to debian-user and
debian-policy.
I have since discussed it on #debian, and thought at great length about it.
Before commenting on this email, I suggest you also read bug 15797 which
touches on the issues in some detail.
The problem is as follows:
Modern perl applications all rely on the new perl module system which is
conceptually parallel to shared libraries, although the shared code is not
normally binary (it can be). Debian users can acquire modules in three
different ways:
A reasonably large selection of modules come with the basic perl packages
perl,
perl-base. These are installed into /usr/lib/perl5.
There are around 20 or 30 supplementary perl libraries packaged by debian
maintainers (examples are libwww-perl, mysql, msql, perl-tk, perl-gtk, and
so on).
These also install their stuff into /usr/lib/perl5.
Finally a debian user might want to install their own perl modules. In
fact, anyone who does any kind of development in perl *will* certainly
want to install some perl modules themselves. They will often do this by
using a special package called 'CPAN' - which we *do* supply in our perl
package - which is functionally not unlike dselect. It downloads a master
module list, and gives the user the ability to select and search for
modules. It also has a crude (compared to dselect) ability to compare the
installed versions of modules with those out on the 'net. This can be
reasonably expected to improve. Modules installed by hand go into
/usr/local/lib/site_perl.
So far, so good. Now the problems. The problems arise, of course, with
multiple versions of the same module.
1) A user could install a newer version of one of the modules supplied by
a debian package. He might do this because CPAN had pointed out to him
that he had an older version. Unfortunately, although installation would
probably seem roughly successful, since /usr/local/lib/site_perl is
bizarrely *after* /usr/lib/perl5 (read 15797 to find out why...) in perl's
search path, his new version will not override the old.
2) A new version of a package might install a newer version of the modules
than that installed by hand by the user. In the present system this will
not, in fact, cause a problem - but if we switch the directory ordering, as
I (and Deebugger on #debian is inclined to agree with me) suspect we
should, we will then hit this problem.
I have thought about it hard, and come up with a few possible solutions:
1) (My current favourite) Leave CPAN installing into
/usr/local/lib/site_perl as at present [actually, I'd prefer
/usr/local/lib/perl5, see below..]. Change perl's directory ordering
so that this takes priority. Include as a script in one of the main perl
packages, a module checker, which compares all the modules in
/usr/local/lib/site_perl to those in /usr/lib/perl5, and removes any
versions in /usr/local which are superceded by those in /usr/lib/perl5.
This script would then be called from postinst from any package which
installs its own perl modules (into /usr/lib/perl5, of course).
2) We could try to set up an alternatives system, so that modules are
stored in (say) /usr/lib/perl5_mod/<package_name> and /usr/local/lib/perl5,
and then some maintenance script ensures that /usr/lib/perl5 is populated
with symbolic links to the optimal versions.
3) dpkg could be taught about CPAN (ouch...)
I would appreciate some thoughts on these. If there is general approval,
and if the perl package maintainer is busy, I might write the script in
(1) and submit it to them.
One further point - IMHO, /usr/local/lib/perl5 should exist for modules
installed by CPAN. /usr/local/lib/perl5/site_perl should be genuinely
site-local modules, written by someone local. It should then never be
touched by any scripts at all.
Yours,
Jules Bean
/----------------+-------------------------------+---------------------\
| Jelibean aka | jules@jellybean.co.uk | 6 Evelyn Rd |
| Jules aka | | Richmond, Surrey |
| Julian Bean | jmlb2@hermes.cam.ac.uk | TW9 2TF *UK* |
+----------------+-------------------------------+---------------------+
| War doesn't demonstrate who's right... just who's left. |
| When privacy is outlawed... only the outlaws have privacy. |
\----------------------------------------------------------------------/
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: