Re: merged /usr vs. symlink farms
On Sat, 2021-08-21 at 18:47:50 +0100, Luca Boccassi wrote:
> My recollection (which might be wrong, but a quick look at release
> notes seems to support it with 11.04 having multiarch 2 years before
> Wheezy) is that Canonical led the way with the multiarch effort in
> Ubuntu, and Debian followed with lots of huffing, puffing and
> grumbling.
You mean that time when Ubuntu merged an implementation based on a broken
design with broken interfaces, that was causing dpkg database damage, where
the tech-ctte also tried to force through, in all its wisdom? Right, great
example. (And let's ignore release cadences for more spectacular effect.)
<https://lists.debian.org/debian-devel-announce/2012/03/msg00005.html>
But just wow, such a mischaracterization and deformation of the events.
Sadly, at this point I'm not surprised. This goes along comments such as
that the intersection of packages not using debhelper and shipping
split-/usr files are in the "thousands" (way less than the actual number
of packages shipping those pathnames), or the ones in the paragraphs
below about that mythical bug report, and the single failed attempt to
symlink farm, etc, etc…
> On Sat, 2021-08-21 at 16:20 +0200, Wouter Verhelst wrote:
> > I'm not saying the solution which the dpkg maintainers are proposing
> > is the only valid solution, but if you go and tell them "ah the real
> > problems you point out are irrelevant" then You! Are! Doing! It!
> > Wrong!
>
> Again, if the magnitude of this dpkg bug was really that serious there
> would be visible consequences after almost 3 years of deployments
> across two distributions with who knows how many million instances, and
> yet "having to run dpkg -S again" is all we can see. Where are the bug
> reports? Where are the enraged users with unusable broken system and
> lost data? Where are the reports of Canonical going out of business
> because Ubuntu is unusable?
Just like no one had detected the database corruption in Ubuntu before
I spotted the problem via code review and analysis (which I guess in
your world translates to "opinion"). I'd expect the problems with
aliased directories to be that kind of insidious issue that people
have a very hard time trying to pin point, and which will be getting
worse as time passes.
> The bug is real, nobody doubts that - it has been filed on dpkg 20
> years ago.
You keep repeating this, but I have no idea what bug you refer to.
There's #148258 (from 2002), which is conffile related, and not
actionable and should probably just be closed.
There's #182747 (from 2003), which while apparently similar is
something else completely. This is about the (IMO) misfeature of
supporting a local admin to redirect (not alias) a directory using a
local symlink (mainly for space management reasons). For an explanation
see <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779060#10>.
There's #406715 (from 2007) which is related to the above misfeature.
> What I am taking issues with is the representation of its
> actual, real effects, and thus its severity and the consequences for
> the project. There are a lot of words being spent on how terrible and
> broken and unacceptable the status quo is, and yet not a single link
> to a bug report.
What I'm appalled at is the sloppiness and dogma shown in the name of
a filesystem layout that will have very minimal benefit for final users
(in contrast to some use cases for some admins or installations that
should already know what they are doing, and can manage all potential
downsides in a controlled way through a hack like usrmerge), knowingly
in detriment of robustness and stability.
> By all means, go and fix it, make it a top priority for dpkg to sort
> out, all hands on deck, whatever needed -
To even consider the possibility to support this missing feature in
dpkg would require for it to get support for at least tracking
filesystem metadata (which is has *never* *ever* supported), which is
currently not deployable:
<https://wiki.debian.org/Teams/Dpkg/Spec/MetadataTracking>
Even with that support in place, that just would not give automatic
aliased directory support. It would need no package to ship anything
inside those directories, and it would also need for some package to
ship those aliased symlinks. And then many corner cases would need to
be considered as then dpkg will need to reconcile what's on the
filesystem, on its database and on the various .deb (given that these
have been a shared resource, that it cannot possibly and safely switch
type by itself), w/o also breaking previous expectations. Not to mention
that the general aliasing issues still would not disappear.
> but to demand the entire project has to stand still,
So wait, when it suits you the "entire project" is involved and cannot
do stuff, but when it does not the "entire project" is not required to
do anything because the proposed solution magically solves stuff for
free with no effort involved… right.
> and to de-facto derail the effort put in to catch up with the rest
> of the world
This again. The rest of the world is not Debian, and as Wouter nicely
put it, we used distinguish ourselves for doing things right. Also while
I'm for merging into /usr, selling it as some kind of technological
advancement breakthrough sounds rather ridiculous. But I guess times
change, and "transitions" now are not planned nor thought nor designed
and people just throw stuff to the wall and just check whether it
sticks or not…
> by imposing an unworkable, demonstrably failed solution (symlinks farm)
So you keep claiming…
> to work around a dpkg bug instead of fixing it internally,
…
> to me does not seem acceptable in any
> way, shape or form without some real, serious evidence that the sky has
> indeed fallen.
If that's an approach to reliable and stable systems where that's
the binary "the sky has fallen" or not, I supposed it follows that
in that world view stuff like security is handled such that an
analysis ("opinion", sorry) of a vulnerability can be downplayed
and ignored because there are no reported botnets riding on.
I guess I might be old fashioned or something, but I'm not interested
at all in sharing such world.
Unimpressed,
Guillem
Reply to: