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

Bug#259302: Patch update against base-files 3.1



Santiago Vila <sanvila@unex.es> writes:

> On Sat, 4 Dec 2004, Andreas Jochens wrote:
>
>> However, I had severe problems with 'glibc' upgrades when the '/lib64' 
>> symlink was created by 'glibc' instead of 'base-files'. 
>> Basically, everything stopped working during the upgrade because 
>> the '/lib64' temporarily disappeared and the binaries could not 
>> find the dynamic linker anymore.
>
> If glibc, which contains all the essential libraries and it's in the
> best position to do it, have problems creating the symlinks, imagine
> the *huge* mess that might happen if we finally put the symlinks in
> base-files and we want to remove it later for multiarch support,
> considering that base-files and glibc do not have any sort of "sync"
> between them. That is my main objection for putting the symlinks in
> base-files.

The problem is we already have it in base-files on every installed
amd64 system. The problem isn't having it or changing it later but
moving it between packages.

> Could you please provide details about the problem of having the
> symlinks in glibc?
>
> Is it that glibc has a versioned Replaces: base-files and dpkg removes
> the symlink in base-files before installing the one from glibc,
> creating a big window during which /lib64 does not exist at all?
>
> In such case I think it would be completely acceptable that the preinst
> simply manipulates /var/lib/dpkg/info/base-files.list to remove
> the /lib64 entry from it, so that the Replaces becomes innecessary.

Urgs, that is a dirty hack. Also what preinst do you mean? base-files?

IMHO at a minimum the base-files without the /lib64 link has to
predepend on a libc6 with the link and libc6 might have to replace
older base-files to avoid dpkg complaining about overwriting /lib64
(or is that unneccessary for links of dirs?).

> I believe dpkg should not have problems installing a symlink when the
> symlink already exists in the filesystem and does not belong to any package.
>
> Sure, it would be a hack, but if the symlink is in base-files, it
> could be that we need a much bigger hack to remove it later, or worse,
> it could be that we are in a dead-end and there is no possible hack
> for the multiarch transition.

Iirc dpkg does never change a dir to symlink or symlink to dir in
order to preserve the local admins choices (like moving /usr/lib to a
different drive for space reasons).

Maybe it is enough if base-files predepends on a libc6 with the link
and nothing else.

MfG
        Goswin

PS: Since we are talking unreleased inofficial debs here without any
long time not upgraded systems the base-file predepends could be amd64
only just until everyone has updated and could then be phased out. We
probably don't need to burden sarge with that.



Reply to: