On Sun, 24 Feb 2019 14:16:03 +0100 Johannes Schauer <jo...@debian.org> wrote: > I found that some important arguments are still missing. A recent mail by > Guillem [1] nicely summarizes also many of my own thoughts. I'm going to paste > the relevant content into this mail for convenience of the reader:
I think those have actually been addressed before, even if they're not explicitly listed or refuted in the draft. Guillem seems to accept moving away from current filesystem layout, but also opposes the resulting layout used by other distributions (which includes the /bin -> /usr/bin symlink). Do you share that view? The main issue with Guillem's view is that in practice it would make the transition more cumbersome and error-prone. If there is no directory-level symlink, then migrating things requires either creating individual symlinks for everything instead, or having a flag day to make sure nothing references the old location any more. In practice either of those is more problematic than a directory symlink. > > 1) The merged-/usr-via-symlinks deployment method used by both > > debootstrap and usrmerge, means that those systems will get > > permanent filesystem aliasing problems, forever. Even when all > > files might have been moved to their /usr counterparts in the > > packages! This is due to the fact that different pathnames can > > end up pointing (before any canonicalization!) to the same dentry. > > > > This does not only affect dpkg (dpkg, dpkg-divert, dpkg-trigger, > > etc), and update-alternatives (in a worse way), but any program > > that uses pathanmes in the filesystem as keys in databases f.ex. This has already been in use, both in Debian and in other distributions, for quite some time. No major problems have been reported. Arguing about "any program" is not useful when discussing only Debian choices, because the layout is used by other distributions in any case and programs have to cope. > > 2) It bypasses the packaging system understanding of what is on the > > filesystem and creates mismatches between what's on binary packages > > and what's on disk. This also has not caused major problems, but it can be solved straightforwardly in dpkg if needed. Dpkg can special-case any legacy /bin path contained in a package and internally change it to /usr/bin. > > 3) Switching packages to the merged-/usr layout could have been > > accomplished automatically via debhelper for a coverage of around > > 99% (?) of the archive. With something along the lines of: This would just create a more cumbersome and error-prone migration. > > 4) Due to having to support the broken merged-/usr-via-symlinks > > deployment, when we want to move the contents of the binary > > packages to the merged-/usr layout, we require now to include tons > > of logic in (probably new) maintainer scripts, when we have been > > trying to remove them altogether. :( With even more files untracked > > by dpkg itself, bypassing the packaging system even more, when the > > compat symlinks could have been shipped in the binary packages. This seems to be based on questionable implicit assumptions. Namely that the move would want to create an individual per-file compatibility symlink in /bin for non-merged systems, and this is the part which would cause problems. There seem to be neither technical reasons to prefer non-merged systems for any use nor practical difficulties migrating existing systems to the merged layout, so long-term it seems OK to deal with this by just requiring merged-usr and not shipping any individual compatibility links for non-merged systems. This allows the simplest possible move - just install the files in /usr normally. > > 5) Most new installations will not even benefit from this hacky and > > rushed deployment, as long as they do not use a separate parition > > for /usr! Is there a point to this? Yes, migrating to merged /usr is mostly an internal implementation detail for most users. But this does not exactly give any argument against the migration, other than calling it "hacky and rushed" while it seems to be the most practical way to do things. > > 6) The merged-/usr-via-symlinks deployment hack is irreversible right > > now. This is not a reason to avoid using the merged-usr layout. > Just like Guillem, I'm personally not against merged-/usr but against how we > implement it. Not against, except for the directory symlinks being part of the merged-usr layout?
