Bug#259302: Patch update against base-files 3.1

[Santiago Vila <sanvila@unex.es>]

On Sun, 5 Dec 2004, Goswin von Brederlow wrote:

> The problem is we already have it in base-files on every installed
> amd64 system.

Yes, I'm fully aware of that. See the message I wrote after that.

> > 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?

I was referring to the preinst of libc6 here, read my next message
however. It could be better to accumulate all the hacks in the amd64
version of 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.

I don't think that will be enough. libc6 and base-files will conflict
if they both contain the symlink, but if libc6 has a Replaces: base-files
for the symlink, the system might break due to dpkg's not atomic
handling of replaces.

>         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.

Yes, such unreleased status and the simplicity of the base-files
package is exactly why I propose to hack your base-files version a little
bit more so that /lib64 is provided without being part of the .deb first,
then libc6 can take care of /lib64 without a Replaces: field, and finally
you can remove the special amd64 base-files version and use the normal
base-files again.