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

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"'

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.


Reply to: