Re: Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)
[ Barak, I appreciate your mail, but *sigh*, it's still frustrating,
as pretty much many of the mails related to this, as they keep
ignoring what has been said, and I feel like talking to a wall. :/ ]
On Thu, 2021-07-22 at 11:48:34 +0100, Barak A. Pearlmutter wrote:
> Seriously? Being able to type
>
> dpkg -S $(which cat)
>
> instead of
>
> dpkg -S $(which cat|sed 's:^/usr::')
>
> is the big user-level pain point?
No. As I've mentioned before, f.ex.:
* dpkg, dpkg-divert, or update-alternatives are unable to detect file
conflicts and thus might allow silent overwrites of random stuff on
disk (3rd-party/local packages where we have no control over, or
even packages from old Debian releases come to mind),
* when moving files across packages and across aliased directories,
these pathnames might end up disappearing depending on the unpack
order (new/old Debian or 3rd-party/local packages too),
* dpkg-deb -x on the root directory (yes, people use this to recover
systems) with any .deb that contains files on real directories under
«/» (3rd-party/local packages), will replace the symlinked directories
with real ones,
* dpkg-statoverride used with aliased pathnames that exist on disk
but unknown to dpkg, will fail to apply the overrides (itself and
dpkg on unpack), this could have security implications f.ex.,
* dpkg-triggers used with aliased pathnames that exist on disk but
unknown to dpkg, will fail to activate triggers,
Also, yes, anything using dpkg-query is now broken, take for example the
cruft package, the problem is that there are way more things depending
on this interface.
But the aliasing problem is a general one. Take the /etc/shells
mentioned recently on d-d, the admin needs to remember to always add
two entries (/ and /usr) to make sure things will match by any random
program accessing the file for its checks.
Regarding your dpkg-query example above, using which(1) and assuming
a PATH set to prefer /usr directories (which AFAIR is the current
default) would mean that once all objects have moved in the .debs into
/usr, the former would always work, but at that point the latter would
not. Also that assumes people would use which(1) or similar, or even
fully canonicalize the pathname, which might or might not have anything
to do with what dpkg knows about on its database.
> People seem pretty worked up over this, but honestly I'm not
> understanding why. We already have $PATH which (let's be honest) is an
> ancient crappy workaround for the original Unix sin of not keeping all
> the executables in one place. (And analogous wheel-reinventing goo for
> /lib vs /usr/lib vs /usr/lib/x86_64-linux-gnu, etc.) Given that,
> moving them around isn't supposed to be a big fuss. Oh, but there are
> also shebang #!/bin/foo issues and other hard coding. The shebang is
> already such a mess that people use #!/usr/bin/env foo, just to get
> foo searched in $PATH. (85 of the 890 scripts in /usr/bin/* on the
> machine I'm typing this on use a /usr/bin/env trampoline.) Nobody
> would ever consider having /bin/foo and /usr/bin/foo be different
> programs, that would be madness. The TC basically concluded that the
> distinction between /bin and /usr/bin, etc, had totally broken down
> and there's no advantage to keeping them distinct, plus initrd is the
> new /bin. (Pretty much the same argument as in the design of plan9.)
> I'm not seeing much argument against that, except for nostalgia.
In case this is not clear, and as I've mentioned also countless times
already, I have no problem with merging contents of directories from /
into /usr, I've done that for all packages I maintain (where no compat
symlinks were required). I do have a huge problem with the approach
that has been forced into the distribution disregarding the packaging
system and going on its back, though.
You might want to take a peek at
<https://wiki.debian.org/Teams/Dpkg/MergedUsr>.
Can any of the above be avoided? Well certainly, in the same way you
can probably cross a mine field safely, you'll just need to always be
aware of any of these things, and verify everything you install, and
all pathnames you use, etc. I'm not sure how this is in any reasonable
universe an acceptable way to expect end users to use the system TBH.
Thanks,
Guillem
Reply to: