Kurt Roeckx <k...@roeckx.be> writes:
> On Mon, May 25, 2009 at 06:22:39PM +0100, Adam D. Barratt wrote:
>> On Sat, 2009-05-16 at 21:48 +0200, Kurt Roeckx wrote:
>> > Some packages ship a file in /usr/lib64/ on amd64, which
>> > is a symlink (provided by libc6). This breaks the system
>> > when that package is removed.
>>
>> Where "that package" is libc6 or the other packages installing direct in
>> to the *64 directories? I only ask because from a quick test in a
>> chroot, installing and purging such a package (hardinfo, predictably :-)
>
> Last time I've tried that, the /usr/lib64 symlink was gone,
> and I think that was in the past year. Maybe something changed
> in dpkg in the mean time.
>
>
> Kurt
That would be a dpkg bug or regression. A directory can be a link
somewhere else and that must be preserved. At least before bind mounts
that was the way to move data to another disk with more space.
What normaly breaks is libc6. dpkg complains that /usr/lib64 is also
contained in another package (that with the directory) and refuses to
unpack the symlink. Symlinks are handled like files and can only be in
one package. So no more libc6 upgrades unless --force-overwrite is
used.
Arguably there is a dpkg bug here too. dpkg should not allow a
directory of the same name as a symlink in another package. But for
directories there is plainly no duplicate file check being done as
dpkg has no knowledge of the file type of already installed files /
dirs / links in its database.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
