Hi all..
IMNSHO, there is a problem with the integration between our perl package,
and the CPAN module.
The CPAN module (for those who don't know about it) gives the perl
administrator functionality comparable to dselect/dpkg, for installing
perl modules. This is very useful indeed. However, it 'conflicts' with
that functionality supplied by the dselect/dpkg combo in several ways:
Some very popular perl modules have been packaged as .debs. This is
good in terms of user visibility, but bad in that it provides users with
two differents ways to install perl packages, and they'll go in different
places - dselect will put them in /usr/lib/perl5, while if they use CPAN
with the default config, they go into /usr/local/lib/site_perl.
Some popular perl modules come as part of the perl package. This is
certainly a good thing, but....
When a user uses CPAN to update to the latest version of something,
they will have two versions of the same something. Not only that, but
perl's default search path puts /usr/local/lib/site_perl *after*
/usr/lib/perl5 - so if they try to replace an existing module, they will
appear to suceed, but the old module will be used.
E.g:
njm25# grep VERSION /usr/lib/perl5/HTML/Parser.pm
use vars qw($VERSION);
$VERSION = sprintf("%d.%02d", q$Revision: 2.13 $ =~ /(\d+)\.(\d+)/);
njm25# grep VERSION /usr/local/lib/site_perl/HTML/Parser.pm
use vars qw($VERSION);
$VERSION = "2.17"; # $Date: 1998/04/28 06:49:54 $
njm25# perl -MHTML::Parser -e 'print $HTML::Parser::VERSION,qq(\n);'
2.13
So you see, version 2.13 of HTML::Parser came with some package (I suspect
it comes with libwww-perl). But I used CPAN to install 2.17 (which has
then gone in /usr/local/lib/site_perl). But, 2.13 is being run.
If I explicitly specify /usr/local/lib/site_perl in a '-I' flag, it takes
priority. This is of course, not very desirable.
Now, of course, I could choose to set the CPAN module to go directly
to /usr/lib/perl5 (but that is a *BAD THING*). And, as far as I can find
so far, there is no way to permanently change perl's include search path.
So the user cannot simply (for example) install a new version of
Term::Readline.
I have also Cc:ed this to debian-policy, because on the one hand perl use
is so fundament to debian it's almost policy ;) but primarily because I
think this problem may well come up again w.r.t. some other complex
package which allows built-in module downloading (a future version of
GIMP, maybe).
Does anyone have any thoughts on this - in particular, is there any good
reason I shouldn't file a bug against perl for listing
/usr/local/lib/site_perl *after* /usr/lib/perl5 in it's @INC array - or,
have I made an awful mistake, and does the whole system in fact work
perfectly well?
If I have correctly analysed the problem, then the 'right' answer involves
dpkg and CPAN somehow understanding each others directory and version
structures - a hard problem. I suspect that altering the @INC priorities
will solve most problems, though...
Yours,
Jules Bean
/----------------+-------------------------------+---------------------\
| Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd |
| Jules aka | | Richmond, Surrey |
| Julian Bean | [EMAIL PROTECTED] | 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 [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
