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

Re: dpkg bug #156463: second opinions?



Adam Heath wrote:

On Fri, 30 Aug 2002, Adam C Powell IV wrote:
Greetings,

Just writing to request a "second opinion" on this bug.

Current dpkg behavior does not allow a package to replace a directory
with a symlink during upgrade.  This broke a libc6-dev upgrade when I
made an unstable chroot from a potato tarball on an ARM system a couple
of months ago.  See bug 151669 and the debian-arm thread I started a
while ago (URL below) for details.

http://lists.debian.org/debian-arm/2002/debian-arm-200208/msg00017.html

Wichert promptly closed my bug reporting this, #156463, saying "this is
the way it's supposed to be".

IMHO, this is broken behavior, as it creates a limitation on package
upgrading which has nothing whatsoever to do with policy, or with any
sound reason for that matter.  Furthermore, that upgrade behaves
differently in this regard from remove then install (which works just
fine) sounds bizarre.  Is there something I'm overlooking such that
things should be this way?

Please cc me in replies as I'm not subscribed.

So, what happens when someone does this:

==
mkfs.ext2 /dev/sda5
mount /dev/sda5 /mount/sda5/
cp -a /usr /mount/sda5/usr
cp -a /var /mount/sda5/var
rm -rf /usr
rm -rf /var
ln -s mount/sda5/usr usr
ln -s mount/sda5/var var
Uh, then /usr and /var are simlinks?

I think you misunderstand part of the bug. There was a directory which was only in use by a single package. doing "dpkg --remove libc6-dev" would have removed it. Having removed it, "dpkg --install libc6-dev...deb" would have created it as a symlink. But merely upgrading libc6-dev resulted in its being left as an empty directory, causing packages to fail to build (because it was a subdir of /usr/include/asm).

In your situation, you replace directories which *tons* of packages (every package?) use, which is an entirely different matter. If *any* other installed package had put files in /usr/include/asm/arch, then I could understand not replacing that dir with the new symlink. But they didn't.

How is this not a dpkg bug?

Zeen,
--

-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe! <http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg>





Reply to: