[ 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
