dependency nightmare
yesterday I was installing a variety of software in a testing machine,
and discovered just how painful the debian perl modules packages can
be. It was a nightmare I thought dpkg was supposed to prevent.
I'm finding that perl packages install into
/usr/lib/perl5/<ver>/... and depend on some perl, but that I have a
newer perl version that doesn't include the path they installed into,
but still meets the dependancy.
For example, libapache-mod-perl version 1.25-4 installs
/usr/lib/perl/5.6.0/Apache.pm, and is dependent on perl (>= 5.6.0-20),
perl (<< 5.7). However, my perl is version 5.6.1-5, and it's @INC does
not include that. It's:
webtools:~# perl -e 'print @INC,"\n"'
/usr/local/lib/perl/5.6.1/usr/local/share/perl/5.6.1/usr/lib/perl5/usr/share/perl5/usr/lib/perl/5.6.1/usr/share/perl/5.6.1/usr/local/lib/site_perl/usr/lib/perl5/5.6/i386-linux/usr/lib/perl5/5.6/usr/lib/perl5/5.005/i386-linux/usr/lib/perl5/5.005.
I'm seeing this sort of problem with almost all of the perl modules
I've tried to install. While this might be because testing lags behind
unstable, I don't think the packages should allow for this broken
state. I would file a bug report, but I'm not really sure what
against, it seems like a bug in the way things are packaged.
I think it perl modules are going to install into
/usr/lib/perl5/<ver>, than the module must depend on an exact version
of perl. Perhaps something similar to the way kernel modules are
packaged, but I'm not a debian developer, and don't know nearly all
the policy.
seph
Reply to: