Re: dependency nightmare
I have been watching the same problem several times with postgresql after
on unstable. The only remedy I found was to create link
/usr/lib/perl/<new version>->/usr/lib/perl/<old version>
For the last upgrade I do it by issuing the command:
# ln -sf /usr/lib/perl/5.6.1 /usr/lib/perl/5.6.0
I don't believe this is a very good remedy but it works for me.
----- Original Message -----
From: seph <email@example.com>
Sent: Friday, August 10, 2001 5:37 AM
Subject: 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.
> To UNSUBSCRIBE, email to firstname.lastname@example.org
> with a subject of "unsubscribe". Trouble? Contact