Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.devel > #100853 > unrolled thread

Re: Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

Back to article view | Back to linux.debian.devel

Contents

  Re: Re: merged /usr considered harmful (was Re: Bits from the  Technical Committee) "Barak A. Pearlmutter" <bap@debian.org> - 2021-07-22 12:50 +0200
    Re: merged /usr considered harmful (was Re: Bits from the Technical  Committee) Marco d'Itri <md@Linux.IT> - 2021-07-22 14:10 +0200
      Re: merged /usr considered harmful (was Re: Bits from the Technical  Committee) Luca Boccassi <bluca@debian.org> - 2021-07-22 16:30 +0200
    Re: Re: merged /usr considered harmful (was Re: Bits from the  Technical Committee) Guillem Jover <guillem@debian.org> - 2021-07-22 14:50 +0200

#100853 — Re: Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

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?

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.

It seems that dpkg is ground zero for problems that occur during the
transition itself, and for the problem of handling the transition
gracefully. I for one am enormously impressed with the quality of
dpkg: its amazing robustness, the way it's evolved to support hooks
and such and really been the cornerstone of the distribution. So I
think we should take the dpkg maintainer's concerns seriously. But
frankly I don't quite understand them.

--Barak Pearlmutter.

[toc] | [next] | [standalone]

#100854 — Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Multipart message — attachments visible in raw view] — view raw

On Jul 22, "Barak A. Pearlmutter" <bap@debian.org> wrote:

> People seem pretty worked up over this, but honestly I'm not
> understanding why.
Because they are scared by new things, hence they oppose merged-/usr 
(and systemd before that, and udev even before...).
But since they cannot admit that, then they need to rationalize by 
inflating the effects of minor bugs or usability issues.

Basically all new systems are installed with merged-/usr since Debian 
10, and since obviously this has not caused noticeable issues (or at 
least, any which could not be fixed) then we must treat with skepticism 
any such claims.

-- 
ciao,
Marco

[toc] | [prev] | [next] | [standalone]

#100859 — Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Multipart message — attachments visible in raw view] — view raw

On Thu, 2021-07-22 at 14:04 +0200, Marco d'Itri wrote:
> On Jul 22, "Barak A. Pearlmutter" <bap@debian.org> wrote:
> 
> > People seem pretty worked up over this, but honestly I'm not
> > understanding why.
> Because they are scared by new things, hence they oppose merged-/usr 
> (and systemd before that, and udev even before...).
> But since they cannot admit that, then they need to rationalize by 
> inflating the effects of minor bugs or usability issues.
> 
> Basically all new systems are installed with merged-/usr since Debian 
> 10, and since obviously this has not caused noticeable issues (or at 
> least, any which could not be fixed) then we must treat with skepticism 
> any such claims.

Not only all Debian systems, but all Ubuntu systems since 2019 (iirc)
and other derivatives too. Still waiting for the sky to fall.

-- 
Kind regards,
Luca Boccassi

[toc] | [prev] | [next] | [standalone]

#100855

[ 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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.devel

csiph-web