On Fri, 09 Jun 2023 22:14:16 +0200, Helmut Grohne wrote: > On Fri, Jun 09, 2023 at 02:42:25PM -0500, Richard Laager wrote: > > Because you want to support non-usr-merged systems, e.g. for derivatives? > > dpkg is used in any different contexts. A very simple example of a > non-merged system would be Debian stretch. For another dpkg really is > being used for things that are not based on Debian. While it is the > Debian package manager, it has uses beyond dpkg has (thus far) stayed > away from imposing policy on the filesystem layout.
Refusing to delete /bin etc. doesn't mean that dpkg imposes any policy on the filesystem layout. The change would also be small enough that it would be easy to disable it, but I can't think of any usage of dpkg for which that would be needed. > > They aren't going to want to delete /bin either, so I don't see how a > > special-case preventing deletion of /bin would be problematic. > > Indeed. However, if you actually manage to trigger this, it can be very > surprising. Your hard coded list would also contain /lib32, /libx32 and > /libo32. Then you install some mipsen packages, remove them and wonder > why /libo32 does not go away. piuparts is definitely unhappy at this > point. I am quite sure that this behaviour would break something. What I > am not sure about is whether accepting such breakage is a reasonable > trade-off. I can't really think of anything that would break with having an extra directory or symlink around. And if base-files ships the symlinks they would always be there and piuparts would be happy. > > Later, whatever replaces /lib64 with a symlink needs to deal with this, but > > that's not significantly different than whatever it was going to do anyway, > > right? Just do this: > > > > 1. Whatever safety checks are appropriate. > > 2. Unless already verified to be identical by #1, hardlink > > /lib64/ld-linux-x86-64.so.2 to /usr/lib64/ld-linux-x86-64.so.2. This might > > be just a particular instance of the more general case of hardlink > > everything from /lib64 into /usr/lib64. > > 3. Unlink everything from /lib64. > > 4. Unlink /lib64. > > 5. Symlink /lib64 to /usr/lib64 > > I think we start from the premise that /lib64 already is a symlink and > as long as libc6 actually ships /lib64 (even if empty), dpkg won't > delete it. What we will not get here is getting rid of the aliasing and > we will also be unable to ship /lib64 as a symlink in any data.tar > (since that would be a directory vs symlink conflict, which has > unpack-order-dependent behaviour, which is bad). But if all packages in trixie are changed to not ship /lib64 anymore, there wouldn't be a conflict in trixie anymore? If we have the following situation: - We change dpkg to never delete /bin, /lib, /lib32, /lib64, /libo32, /libx32, and /sbin. We can also change dpkg in bookworm to not do this so that we are sure that when upgrading to trixie we have a dpkg that won't delete any of these symlinks. - All packages in trixie are changed to have their files moved to /usr. - Base-files will include the symlinks In the case of bootstrapping no trixie package will have any files in /bin etc. so there wouldn't be a directory vs symlink conflict. From what I understood we need to change the bootstrap protocol to make sure that base-files is unpacked before anything is run so that /bin/sh and ld-linux.so are available. To me that seems to be a simple change to make and it should also be possible to make this small change in the bootstrapping tools in bookworm. In the case of upgrading we already have all the symlinks in the filesystem. Installing base-files when there are still packages installed with files in /bin etc. shouldn't be a problem as far as I understand it. And we changed dpkg to never delete the symlinks when no package ships the /bin directory anymore so it also shouldn't be a problem if all packages that used to ship /bin etc/ are upgraded before base-files is upgraded. Kind regards, Jeroen Dekkers
