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