Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)
On Mon, 19 Jul 2021 03:36:59 +0200, Guillem Jover <guillem@debian.org>
wrote:
>If by "very minor bugs" you mean that 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,
> * when moving files across packages and across aliased directories,
> these pathnames might end up disappearing depending on the unpack
> order,
> * dpkg-deb -x on the root directory (yes, people use this to recover
> systems) with any .deb that contains files on real directories under
> «/», will replace the symlinked directories with real ones,
>
>then, yes, I guess "very minor" indeed. But then I completely object
>to this being classified as bugs in dpkg, as this has been shoved in
>disregarding that dpkg does *not* support this, and it would require
>new *features* to be implemented, so this "transition" is founded on
>assuming features that do not exist, or completely going behind
>dpkg's back, which sounds great I guess…
In an ideal world, would the package manager not be a service utility
to SUPPORT policy and adapt to changing environment contitions instead
being a showstopper for innovation?
Who is the dpkg maintainer to challenge the decisions of the entire
project? I fully understand that there is only ONE dpkg maintainer,
but a utility THIS central to the entire ecosystem not being team
maintained is a HUGE part of the problem.
And no, I cannot help and no, you wouldn't want me to write a single
line of code in a package THIS central.
>The problem in general is that this layout introduces unreliability
>and silently induced breakage stemming from this flawed filesystem
>layout, which is going to affect the people that are going to benefit
>the less from its properties, and are the less experience to deal with
>it.
Would it not be dpkg's job to work around these flaws? It's not that
every other component of a Debian system are perfect.
>And here we are getting the project installing by default systems that
>are fighting the packaging system and going on its back, to enable a
>filesystem design layout mostly experienced admins will benefit from
>in very special deployment conditions, where final users can very
>easily suffer from its introduced unreliability (from 3rd-party repos
>or locally built packages, etc, f.ex.).
I must be missing some thing, but isn't it the experienced admins
facing reinstalls of vital systems when we finally move to a
completely merged /usr, because these usually currently have /usr on a
dedicated mountpoint?
>Because the above has been brought up before and the proponents are well
>aware of these, I'm afraid at this point the only thing that comes to
>mind is negligence, TBH. :/
on both sides of the conflict, yes.
Greetings
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Reply to: