Hi, On 8/17/21 8:02 PM, Simon McVittie wrote:
However, some people (most notably the dpkg maintainer, who has thought about this more than most) argue that merged-/usr's "aliasing" symlinks /bin -> usr/bin, etc. are unsupportable, and the only correct way to consolidate static files to be physically located under /usr is to gradually build up symlink farms below /bin and so on.
I agree that it's likely the only thing we can do with the version of dpkg that we ship now, and that will have to handle the upgrade for any users that move from one stable release to the next provided there is no project consensus to deviate from "apt dist-upgrade" as the preferred method of upgrading to the next release.
The two main constraints are:1. At any point that the resolver in stable apt or stable aptitude invokes a new dpkg call, the PATH needs to contain "sh", "rm", "tar", "diff", "dpkg-deb", "ldconfig" and "start-stop-daemon", and the first entry it finds will be examined with stat() for ugo+x, or dpkg will declare the system to be broken and refuse to operate.
2. In any order of operations generated by the apt and aptitude resolvers from any starting configuration consisting of packages from stable, backports, testing and unstable (but not older), maintainer scripts need to work.
That is an awfully big search space that we'd have to cover if we still want upgrades to work smoothly for all users, including those who are installing backports or pull single packages from testing or unstable.
We can add features to dpkg to facilitate an instantaneous switch from the symlink farm to a full usrmerge system, but this could also be encoded in a preinst.
The algorithm would be 1. if the target in the toplevel directory is already a symlink, we're done2. if the target in the toplevel is a directory, verify that it only contains other directories and symlinks. Optionally, verify that the same names exist below the target of the link we're trying to create
3. rename old dir 4. create symlink 5. remove old dirThis would work either as a change to unpack.c:1373 and following, or as a preinst of a package shipping the symlinks in the data archive. Both places would be effectively atomic from the view of all affected components, and both would require the new package to conflict with any current package that ships a file below a path that needs to be moved.
What is unclear is how that new package would be pulled in, both during installation and during upgrade, as it would have to be unpacked rather late, and we'd probably have to verify that none of the resolvers tries to --force things in an unexpected way.
The other question is whether we want a more robust, possibly declarative, system to determine the contents of the initramfs, as that effectively takes over the function of the root filesystem.
Simon
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature