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

Re: /usr/lib64 or /usr/lib



Sven Joachim <svenjoac@gmx.de> writes:

> On 2011-06-13 12:11 +0200, Goswin von Brederlow wrote:
>
>> Sven Joachim <svenjoac@gmx.de> writes:
>>
>>> On 2011-06-11 09:22 +0200, Goswin von Brederlow wrote:
>>>
>>>> Except for how dpkg behaves. If your package has a file in /usr/lib64/
>>>> and gets installed then dpkg records that that directory belongs to your
>>>> package. Then the next time libc6 gets updated dpkg will try to unpack
>>>> the /usr/lib64 symlink and fail because you can not replace a directory
>>>> of another package with a symlink.
>>>
>>> Er no, this is not how dpkg behaves.  It never converts symlinks to
>>> directories or vice versa, so the actual outcome is¹ that your file gets
>>> actually installed into /usr/lib through the symlink.  This means that
>>> if another package starts shipping a file with the same name in
>>> /usr/lib, dpkg will not notice the file conflict which is bad.
>>
>> Please read again. Nothing gets converted. dpkg just fails with a file
>> overwrite error because /usr/lib64 belongs to another package and is not
>> a directory in libc6. And only directories are allowed to be in multiple
>> packages.
>
> You seem to have a very old version of dpkg, in this situation there has
> been no file overwrite error for a few years:
>
> ,----
> | dpkg (1.14.6) unstable; urgency=low
> | [...]
> |   * Do not consider it a file conflict if the package contains a symlink
> |     to a directory where the existing symlink on-disk points to the
> |     same place. Closes: #377682
> |     Thanks to Ian Jackson.
> | [...]
> |  -- Guillem Jover <guillem@debian.org>  Wed, 05 Sep 2007 07:36:02 +0300
> `----

It's been a while since I've seen the problem. Not sure if it has been 4
years or not. We had this issue a lot with KDE packages early in the
amd64 port.

The patch from #377682 might fix this issue for upgrades. But that
leaves the problem of new installs. If the package with the
/usr/lib64/foo file is unpacked first then /usr/lib64 is not a symlink
and then libc6 still has a file overwrite problem.

So overall this changes nothing.

MfG
        Goswin


Reply to: