On Mon, Jul 19, 2021 at 03:10:42PM +0200, Michael Biebl wrote: > Hi Guillem > > Am 19.07.21 um 03:36 schrieb Guillem Jover: > > What I've also said multiple times, is that > > merged-usr-via-moves-and-symlink-farms could have been implemented in > > a fully automated way, by debhelper, w/o requiring any maintainer scripts, > > all with full cooperation and managed by dpkg, with .debs shipping > > actual tracked pathnames > I'm convinced this view is way too naive and not implementable in practice > (and yes, openSUSE is a data point that confirms that) > > What you propose is, that each and every package does its /usr-merge > transition on its own. This only works, if packages are independent (enough) > so this actually works. > Unfortunately this is not the case. Take PAM for example. You can't just > recompile src:pam and have debhelper automatically move all files to /usr. > This would break all packages that install a PAM plugin. You have a > transition here, involving many packages.
Why? Nobody is saying the old path should cease to function. The whole point of a symlink farm is that *YOU ADD A SYMLINK* to replace the old path. So then you have /lib/*/security/pam_foo.so -> /usr/lib/*/security/pam_foo.so and your old-pam plugin will still work with new-pam (and vice versa) and there is no need for a transition. I've suggested previously that we can easily make it RC for bookworm to have a file outside a limited set of directories (/etc and /usr would be OK, but notably /bin /lib and /sbin wouldn't be) that is not a symlink. This is easy to detect with a lintian check and reasonably easy to implement, and would not confuse dpkg *at all*. But whenever I bring this up, I hear people say "oh but suse tried it and failed" (well suse aren't using dpkg and there's no reason to assume we'll have the same problem, why don't we try?) or "oh but the /usr/doc transition that worked that way 20 years ago took forever" (that was 20 years ago, our tooling is way more advanced these days) or "oh but that will break bash and you can't upgrade safely without bash" (true, but bash is just the one package and we already have /bin/sh be a symlink and that never made upgrades fail permanently so I don't see how usrmerge is somehow special). I've grown tired of the whole discussion, and the "we must go forward and only our way will work and your ideas are stupid just shut up already" mentality the proponents of usrmerge seem to have. I can understand the use case for usrmerge, and I won't cry over my /bin/sh being essentially the same file as /usr/bin/sh -- but I long for the good old days of Debian where we did things the right way, not whichever is the fastest, because that way, things would *work* in *all* cases, not just the cases that the proponents of some new feature care about. It took us forever to implement the /usr/doc transition, but it was finished and nobody's machine broke. It took us a fairly large time to implement multiarch, but we did it and it works *way* better than in the RPM world. I fail to see why usrmerge is so special that it can't wait until we do things the right way. Sure, there are technical issues with doing things the right way, and we should deal with them. But just throwing them under the carpet and deciding they're only a problem for other people isn't going to help anyone. -- w@uter.{be,co.za} wouter@{grep.be,fosdem.org,debian.org}
signature.asc
Description: PGP signature