Hi, On Sat, 02 Feb 2019 15:38:01 +0100 Didier 'OdyX' Raboud <o...@debian.org> wrote: > Gunnar and myself have started working on a draft, the latest version of > which is available at > > > https://salsa.debian.org/debian/tech-ctte/blob/master/914897_merged_usr/ballot.md
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: [1] https://lists.debian.org/20190219044924.gb21...@gaara.hadrons.org Quoting Guillem Jover (2019-02-19 05:49:24) > The underlaying problem with the merged-/usr-via-symlinks is not > really that it has generated bugs, many transitions we perform incur > those, for the better. The problem is that it has generated those when > it was really not necessary in the first place, has made things > unnecessarily more complicated for everyone, and it's a terrible hack > trying to reap "quick" benefits at the cost of everyhing else, with > long lasting consequences even after a full migration to /usr would > have been finished. And here's why: > > 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. > > 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. > > 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: > > ,--- > D=debian/tmp > for d in /bin /sbin /lib; do > for p in $(find $D/$d ! -type d); do > b="${p##$D/}" > m="$D/usr$b" > if [ ! -e "$m" ]; then > mkdir -p "$(dirname $m)" > mv "$p" "$m" > ln -s "${m##$D}" "$p" > fi > done > done > `--- > > With the property that it would handle gracefully all cases were the > maintainer has checked that no compat symlinks are required and has > then progressively moved the pathname installation to their final > destination under /usr. > > 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. > > 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! > > 6) The merged-/usr-via-symlinks deployment hack is irreversible right > now. Just like Guillem, I'm personally not against merged-/usr but against how we implement it. In addition to Guillems arguments, I also want to make another. With how merged-/usr is getting deployed via debootstrap, we are placing more of the instructions of how a Debian system is supposed to be setup *outside* of the packages themselves (and into debootstrap). It would make a cleaner design if we could have all necessary definitions of how to create a Debian chroot from scratch (on a Debian system) in the packages *themselves* instead of requiring code around the packages that is doing some magic setup (usually debootstrap). With mmdebstrap I am trying to write a POC to show that it is possible to set up a Debian chroot with only very little magic and the help of apt. My goal is to move the remaining magic setup that is currently required into apt and dpkg (the respective maintainers are in favor of that plan but I'm waiting for the buster release). If merged-/usr is getting implemented in the way as it is done by debootstrap, then every debootstrap-like program has to reproduce these mechanisms which are already architecture specific and thus not trivial to maintain over time. It would be more elegant if the way merged-/usr is being deployed is being encoded in the packages themselves so that we can further *reduce* the amount of code that needs to live outside of packages until we eventually need zero setup code before debootstrap-like programs can install binary packages into a chroot. If we decide to deploy merged-/usr the debootstrap way, then we are moving in the opposite direction. Anyways, this is just my own small personal pet-peeve. Please definitely consider the arguments by Guillem above. Thanks! cheers, josch
signature.asc
Description: signature
