Hi, On 8/19/21 4:45 PM, Theodore Ts'o wrote:
FWIW, from following the discussion, I've become more and more convinced that a symlink farm is *not* the right answer, regardless of whether it is done centrally or via individual packages moving files and created symlinks if necessary in individual maintainer scripts.
I think no one likes that idea, but it's the only solution that doesn't immediately fail because it requires a dpkg update that hasn't shipped with the current stable release, breaks local packages (kernel modules, firmware, site-wide systemd configuration), or both.
The dpkg team are rightfully skeptical about introducing a policy decision into the codebase, especially as the next dist-upgrade that users are going to perform will upgrade dpkg somewhere in the middle of the process, after several of its dependencies, which are precisely the packages affected. You can't change default behavior here, you can't introduce a new critical control field because it would create a Depends/Pre-Depends loop, ...
What *could* be done in dpkg is to change the policy for replacing a directory with a symlink. Currently, those entries are dropped, and the comment next to the code responsible for that suggests that the most common scenario where that would be seen were broken packages where someone swapped source and destination while creating a symlink.
But: a new policy would still have to honor file conflicts. The /lib directory cannot be replaced with a symlink until all packages that ship a directory here are gone. Because /lib/ld-linux.so.2 is part of the ABI, that cannot happen on its own, so we can probably narrow this down to "until all packages that ship regular files below /lib are gone."
As I understand it, that is where the symlink farming approach comes from: when the other packages move their regular files out of the way and replace them by symlinks, we have a criterion by which we can decide that the entire hierarchy can be replaced by a symlink.
We still need a mechanism in either dpkg or a package handling the transition that actually performs this operation. If we can do this in a package without touching dpkg, then IMO that would be preferable, but in either case that mechanism needs to be defined first.
Speaking personally, I'm not super excited about /usr unification. But then again, I don't work on projects such as embedded systems, containerized systems, etc., which seem to benefit from /usr unification, and there *is* value in being similar to other Linux distributions.
In my embedded projects, unification is counterproductive, because the initramfs effectively takes on the functionality of the root filesystem, except it cannot be modified in-place anymore with dpkg, and instead I need a script that copies relevant files, follows dependencies and then creates a compressed read-only root filesystem I can use for early boot.
That is about as convenient as using cramfs as the root filesystem, except it needs a lot more memory, and I cannot prepare this on the host.
Starting systemd without /usr, /proc and /sys mounted has been broken for ages, so booting without an initramfs simply does not work anyway there.
With sysvinit, it still mostly works, although some programs (also mostly from the systemd ecosystem) fail before /usr is mounted as they are missing libraries.
My expectation is that systemd will take over initramfs generation during the next release cycle, that might make the situation a bit more bearable as we can then reuse dependency information from units instead of having a shell script recreate it using heuristics.
Right now, a kernel update on a 150 MHz NiosII CPU takes several hours because the initramfs rebuild is just so slow, so for embedded systems, Debian as it is is close to unusable anyway and I believe embedded systems vendors have jumped ship a while ago. I have.
Simon
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature