Re: merged /usr vs. symlink farms
On Sat, Aug 21, 2021 at 02:40:02PM +0100, Luca Boccassi wrote:
> On Sat, 2021-08-21 at 10:26 +0200, Wouter Verhelst wrote:
> > It bothers me that you believe "we've been doing this for a while
> > and it didn't cause any problems, so let's just continue doing
> > things that way even if the people who actually wrote the damn code
> > say that path is littered with minefields and they're scared of what
> > could happen when we finish the tranition this way" is a valid
> > strategy. It goes against everything I was taught to do to write
> > reliable software.
>
> Many people are bothered by many things - such is life. For example, I
> am very bothered that it appears impossible to do any kind of project-
> wide innovation in Debian,
"I don't deny the benefits. I do think that in the current
implementation, the drawbacks outweigh those benefits. That's not to
say it couldn't be done. But if it is done, we should do it *right*.
We're Debian. That's what we do."
-- Colin Walters, https://lists.debian.org/debian-devel/2003/06/msg00475.html
It's true that there are other distributions out there who go for the
quick-and-dirty solution, who want the feature before the benefits,
downsides, and risks have all been fleshed out. There's a reason why I'm
not contributing to those distributions; there's a reason why I don't
use those distributions.
"Doing it right", even if that takes time, has proven benefits.
When the RPM world implemented "multiarch", they only supported
installing 32-bit binaries on 64-bit versions of the same architecture.
They did have that feature implemented and functioning in a few months
or so, but the functionality of it was very limited -- and even today it
has problems, in that the way in which RPM checks that packages are
correct has some inherent heuristics that can make mistakes. Yes, I've
encountered those in practice on CentOS systems that my customers at the
time really really wanted to get up and running again pretty quickly.
When Debian and Ubuntu implemented multiarch (look ma, no quotes), the
time from concept to tests to implementation to public availability was
*much* longer than it was in the RPM world; and while this work was
unfinished, there was a lot of angry nagging about the lack of this
feature and why can they do it in the RPM world you guys are idiots, but
eventually it was implemented; and I think you'll agree that the dpkg
implementation of multiarch is far superior to the RPM one: it's
possible to use multiarch not just for compatibility with 32-bit
versions of your 64-bit platform, as in the RPM world, but *also* for
running arm binaries on x86 with qemu user emulation, or for
cross-compiling, or for various other features that the RPM world can
only dream of.
To get back to the point: I'm not saying we shouldn't merge /usr. We
should; the benefits of a properly merged /usr far outweigh any
disadvantages it may bring. However, having an inconsistent dpkg
database is far more serious than just "oh dpkg -S won't work as
expected". It means dpkg isn't properly keeping track of which files
belong to which package anymore, which means you will have issues with a
package that Replaces: another, or with removing packages (especially
with security-conscious binaries), or with diversions, or with
alternatives, or with file conflicts, or with basically anything that
asks dpkg about locations of files; and just dismissing it with a
handwavy "ah well just run dpkg -S again" is so far removed from reality
that it's not even funny. I think the dpkg maintainers are 100% correct
to point out that that *is* a problem for which currently no viable
solution seems to exist, and that any way forward *must* include a
solution to that problem.
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!
[...]
> The main point is that of course the insights of experts are extremely
> important, incredibly valuable and worth careful consideration,
> especially when making decisions about an unknown future and events yet
> to unfold. But in this case these are predictions about the past, a
> past that already exists and is lived experience for many users here,
> and for all users in Ubuntu.
What that is, is anecdotal evidence. "We've been doing X for a while and
it seems to not kill everything". Cool, great, awesome data points, but
not likely to convince me that there won't ever be any problems. You
can't prove the absense of bugs by anecdotal evidence; you can only
prove the existence of them that way.
What the dpkg maintainers are providing is analytical evidence. "There's
some corner cases here which need to be catered to". You just can't say
that corner cases don't happen because "anecdotal evidence". That's just
not how any of that works.
[...]
> The reality of this industry is that reliable software is an oxymoron:
> the only bug-free software is the one that doesn't exist.
I said "reliable", not "bug-free". It's impossible to write bug-free
software, I think we can agree on that.
However, going all hand-wavy about problems pointed out by people who
know the code intimately is not likely to improve the reliability of the
resulting system.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
Reply to: