Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)
On Thu, 2021-07-15 at 10:13:47 +0100, Luca Boccassi wrote:
> As it has been said and written many times already, in reality this is
> not broken by design at all and in fact it is the only successful
> strategy that has been deployed by other distros - it's what is being
> called merged-usr-via-moves-and-symlink-farms that is broken. We can
> say this with certainty because both approaches have been tried, so
> there's actual real-world data to look at. Just go look at the absolute
> mess that Suse got themselves into by following that solution - a 10-
> years-long massive half-done-never-finished headache that took an
> inordinate amount of work to back out of, and move to the actual
> working solution that everybody else are using - merged-usr-via-
> aliased-dirs. On the other hand Fedora/RHEL had a smooth and simple
> transition using merged-usr-via-aliased-dirs, and that was the end of
> it.
Yes, a single (a couple!?) data point(s) of a strategy used in another
unrelated distribution, with completely different packaging stacks and
ecosystems, which was done very poorly, has been presented repeatedly.
I'm not sure why that has much value TBH.
The above seems to also be confusing how and if a design has been
deployed, with its inherent (short and long term) properties. A badly
performed *deployment* for a better design does not make its properties
bad, in the same way that *deploying* a flawed design faster does not
make its properties better…
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, if it had not been for the mess required
by merged-usr-via-aliased-dirs. :/
> Dpkg has some very minor bugs that rpm/dnf/yum/zypper/whatever do not
> suffer from. So what? It is perfectly normal as it's software and all
> softwares have bugs. They could be fixed, worked around, or ignored,
> like all other bugs.
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…
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.
I've tried to update the <https://wiki.debian.org/Teams/Dpkg/MergedUsr>
with more explicit information, in case some people might have missed
that from previous instances of this discussion, and added an initial
table of properties for both proposals, to avoid cluttering and repeating
it on the list, and to ease updating it.
We do actually have experience with "an aliased" layout from symlinked
/usr/share/doc/ directories, where those are for optional/removable parts
of the filesystem, and the symlinks are even known and managed by dpkg.
And those have been a major and constant source of packaging bugs.
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.).
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. :/
But *shrug*, have at it, I'm tired of the continued and complete
disregard of the unreliability issues and subversion of the packaging
system, which are supposed to be pillars of our project, every single
time. I just replied so that people that might not want to be forced
into this stuff know that there's going to be a way out.
Regards,
Guillem
Reply to: