Bug#528975: lintian: Check for files in /usr/lib64
On Tue, 2009-05-26 at 12:45 +0200, Goswin von Brederlow wrote:
> Kurt Roeckx <kurt@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.
[...]
> 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.
Hmmm. I've just tried the following in a freshly created squeeze chroot,
and nothing broke; is there anything I missed, or has this issue been
fixed somewhere?
1) Downgrade libc6 and libc6-dev to 2.9-4
2) Install hardinfo
3) Upgrade libc6 and libc6-dev to 2.9-12
4) Purge hardinfo
At the end of the process, I still have a working /usr/lib64 in the
chroot and no dpkg errors.
Regards,
Adam
Reply to: