Bug#568487: perl-base: Perl modules installed in place not in %INC during upgrade from etch

Niko Tyni ntyni at debian.org
Sun Feb 21 12:09:52 UTC 2010


tag 568487 moreinfo
severity 568487 important
thanks

On Fri, Feb 05, 2010 at 09:05:13AM +0200, Niko Tyni wrote:
> On Fri, Feb 05, 2010 at 03:05:28PM +1100, Ben Marsh wrote:
> > (env56) vmwprx1:/usr/lib/perl# ls -asl
> > total 24
> >  4 drwxr-xr-x  4 root root  4096 Feb  5 14:39 .
> > 12 drwxr-xr-x 46 root root 12288 Feb  5 14:39 ..
> >  4 drwxr-xr-x  2 root root  4096 Jan 19 12:20 5.10
> >  4 drwxr-xr-x 32 root root  4096 Feb  5 14:39 5.10.0
> > (env56) vmwprx1:/usr/lib/perl# rmdir 5.10
> > (env56) vmwprx1:/usr/lib/perl# ln -s 5.10.0/ 5.10
> > (env56) vmwprx1:/usr/lib/perl# 
> > 
> > NOTE: the 5.10 directory was completely empty when I rmdir'd it.
> 
> That's indeed remarkably broken. It looks like something had created
> /usr/lib/perl/5.10 as a regular directory before you upgraded, and dpkg
> will not replace a directory (even an empty one) with a symlink.
> 
> This is the first report of this failure mode I've seen.
> 
> Do you have any idea what could have created the 5.10 directory, probably
> on January 19th? 

Ping?

I don't really know what to do with this bug. Nobody else has run into this
AFAIK and it seems it can only be triggered by creating a directory
under /usr/lib/ behind dpkg's back.

> Not sure how we could guard against this. Maybe have perl-base.preinst
> that refuses installation if the directory already exists and is not
> a symlink.

I'm inclined to think this isn't worth the complication but other opinions
are welcome.

Meanwhile, lowering the severity.
-- 
Niko Tyni   ntyni at debian.org






More information about the Perl-maintainers mailing list