Hi, On 22.04.23 11:36, Helmut Grohne wrote:
For clarity let me propose the following requirements for the definition
of done:
* All files shipped in Debian packages are shipped in their canonical
location rather than an aliased path.
With proper support in dpkg, that is even somewhat optional.
* The symbolic links are part of some essential package.
Yes, but simple symbolic links in packages would lose against directories in other packages due to the symlink-vs-directory rule.
Treating these as a conflict in the future instead of silently resolving them is not sufficient for transition handling, and making symlinks win over directories and cause aliases to be created automatically will cause curious and interesting effects if someone makes a mistake in a .links file while packaging.
I'd ship the aliases as part of base-files, because that is Essential and has very few reverse dependencies, so giving it a Pre-Depends on a recent dpkg version does not cause ordering issues on upgrade. The Pre-Depends is ignored during bootstrap, but that is fine as the dpkg that is about to be installed is already new enough if it is from the same distribution. In addition, derived distributions that don't want usrmerge will likely ship their own base-files package.
* Therefore no special handling code is needed in bootstrapping tools
for future releases.
For the requirement that unpacking Essential packages gives enough of a running system that installing packages is possible, this unpack phase needs to leave us with a working ld.so in the place the ABI standard requires it, so we probably need to ship the symlinks as symlinks in data.tar.gz, and register them as aliases from metadata so they are not overwritten by a directory.
The alternative would be to keep shipping ld.so in /lib, and let dpkg do usrmerge during the phase where the unpacked Essential packages are overwritten using dpkg.
We won't really be able to avoid at least some ugliness there, given the interaction between usrmerge and the ABI standard.
The alternative would be a consensus that dpkg is simply not expected to always leave the system in a useful state if it encounters certain invalid situations
My main reason for disliking it is that it shifts the effort from the proponents to everyone else. The aliasing effects consume so much mental capacity of regular package maintainers
Exactly that's what I'm feeling as well, and why I want dpkg to be able to reject invalid packages safely so if a maintainer makes a mistake, this can simply be fixed by an updated package.
Testing alone will be an absolute nightmare because we can enter invalid states through multiple avenues, for example, if I have a conflict
a.deb: /bin/test b.deb: /usr/bin/test c.deb: /bin -> /usr/bin
Arguably, we can rule out a lot of test cases by policy. We already have policy that forbids the combination of a.deb and b.deb in Debian. This property can relatively simply be checked on a distribution level and therefore I think we can entirely skip this case.
No, dpkg needs to be able to handle situations forbidden in Policy. File conflicts without declaring "Conflicts:" are also forbidden in Policy, but detecting these is one of the main functions of dpkg.
# move file to /usr, install symlink, then remove symlink, move back dpkg -i a.deb c.deb dpkg --remove c.deb
Again, I think c.deb would likely be essential and since removal of essential packages is undefined, we can remove such cases from our test matrix.
Essential packages can become non-Essential in a later release, can change or be replaced, including piecewise. If we ship the symlinks inside the data.tar, then at least the latter is very unlikely, but I'd think that there needs to be a way to remove aliases.
The only thing we could argue that this can be delayed for a release or two, but this would introduce additional error paths into package removal, and possibly create situations that the package resolver does not understand, so I'd rather not.
Simon
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature