Bug#259302: Patch update against base-files 3.1
Santiago Vila <firstname.lastname@example.org> 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
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.
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.