On Fri, Nov 19, 2021 at 10:06:13AM +0100, Ansgar wrote: > Given packages already did such moves in the last years and you claim > this happens in a non-negligible number of cases, could you please > point to some examples where this already happens in practice? You need a / → /usr¹ and a pkg-a → pkg-b move in the same release. Also, you need to have (the new) pkg-b be unpacked before pkg-a. An example³ would be coreutils/util-linux/… moving everything from /bin to /usr/bin and in the same Debian release splitting out one (or more) of their tools into their own package (as they usually do). As those are essential they will Pre-Depend² on the split out package which guarantees that pkg-b will be unpacked before pkg-a. The result is that the split out tool will be gone from /usr-merged systems – which at that point should be all systems. Another example would be systemd files debhelper moved for some time already while the package does a foo and foo-data split in the same Debian release. Just need to "solve" the unpack order now, but I will leave that as an exercise for the reader. The move and reorganisation is both forbidden by the CTTE for Debian 12 in "Moratorium on moving files' logical locations into /usr" which even describes this problem as one of the reasons for it, but hopes to have it resolved by 13 (without mentioning how). Are you suggesting that Debian will use 13 to move each and every file in / to its /usr counter-path while forbidding that packages including moves are reorganised before 14 ? Good thing 'which' isn't in /bin I guess. (SCNR) Disclaimer: I am as usual not arguing for switching into full speed reverse mode. I would "just" prefer if we acknowledge that problems exist we have to deal with. Its gonna be hard enough to actually resolve them given all bridges have been burned down years ago by pretending its not a problem that dpkg has no idea what is done behind its back to the files its supposed to manage. (The problem itself isn't unique⁴ to /usr-merge, so ideally it would be resolved regardless, but /usr-merge undoubtedly makes heavy use of it so in an ideal world those interested in it would not only acknowledge the problems but actually work together to resolve them. Sadly, that isn't the world we seem to be stuck in at all.) Best regards David Kalnischkies ¹ You could of course also move the other way around. ² You can achieve the same with other dependency types, it is just harder to trigger in simple testcases as apt & dpkg try to avoid the auto-deconfiguration of pkg-a if there is an easy way out. ³ For fun I wrote an apt testcase with coreutils splitting out ln⁴, that might be a bit unrealistic, but you get the idea (attached). ⁴ as, you know, /usr-merge being the last symlink we will ever need
#!/bin/sh set -e TESTDIR="$(readlink -f "$(dirname "$0")")" . "$TESTDIR/framework" setupenvironment configarchitecture 'native' #mkdir -p rootdir/bin ln -s usr/bin rootdir/bin touch ln mkdir -p tree/bin cp -a ln tree/bin buildsimplenativepackage 'coreutils' 'native' '1' 'stable' '' '' '' '' 'tree/bin' rm -rf tree buildsimplenativepackage 'coreutils' 'native' '2' 'unstable' 'Pre-Depends: unneeded-ln' mkdir -p tree/usr/bin cp -a ln tree/usr/bin buildsimplenativepackage 'unneeded-ln' 'native' '2' 'unstable' 'Breaks: coreutils (<< 2) Replaces: coreutils (<< 2)' '' '' '' 'tree/usr' rm -rf tree setupaptarchive testfailure test -e rootdir/bin/ln -o -e rootdir/usr/bin/ln testsuccess apt install coreutils=1 -y testsuccess test -e rootdir/bin/ln -o -e rootdir/usr/bin/ln testsuccess apt full-upgrade -y testsuccess test -e rootdir/bin/ln -o -e rootdir/usr/bin/ln
Attachment:
signature.asc
Description: PGP signature