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}
Attachment:
signature.asc
Description: PGP signature