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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
