[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: merged /usr vs. symlink farms



On Fri, 2021-08-20 at 07:56:33 -0600, Sam Hartman wrote:
> >>>>> "Theodore" == Theodore Ts'o <tytso@mit.edu> writes:
>     Theodore> FWIW, from following the discussion, I've become more and
>     Theodore> more convinced that a symlink farm is *not* the right
>     Theodore> answer, regardless of whether it is done centrally or via
>     Theodore> individual packages moving files and created symlinks if
>     Theodore> necessary in individual maintainer scripts.

There was talk about the huge amount of symlinks required in a symlink
farm setting, but that might have been true for a scenario where those
symlinks would have been handled automatically and transparently.

The huge majority of files under /lib* (which is the actual bulk of them)
should require no symlink farms. Many of the ones under /bin and /sbin
(we are talking about around 240 packages here) might be switchable w/o
compat symlinks after careful consideration (or not…), many of the ones
that require symlinks would need these just for a period of time, and
only a handful would remain (the ones that are part of standard
interfaces, which I'd expect would be mostly shells?). I think the amount
of symlinks currently provided by f.ex. lvm2 and e2fsprogs combined would
amount to more symlinks than what we would eventually end up with TBH.

> Ted, in terms of judging consensus, I'd like to explicitly ACK your
> summary.
> I think that you have accurately described where we are in the
> discussion.
> 
> As you know, one of the ways we can see  how close we are on consensus
> is to look at what happens when someone proposes a summary like you did.
> 
> Simon Richter tried to challenge your summary effectively saying that we
> couldn't have an informed consensus because there were open technical
> issues that had not been addressed.  This was roundly rejected by
> yourself, Philip Hands and Luca Boccassi.

Well then that's a very underwhelming way to judge consensus TBH.

Philip remarked on the falling-sky theme (which I covered in a reply to
Luca elsewhere), and then used a crystal ball to predict the future,
where a particular filesystem layout would pass the test of time in
contrast to dpkg, which apparently (obviously a bit biased here) is such
a trivial detail in our distribution that it can be easily replaced w/o
requiring to scrap everything and starting a new distribution from
scratch.

Luca posted a mess of disinformation.

Ted's reply I've partially covered at the top of this mail. The rest
I've covered in the aforementioned reply to Luca. And some of the
remaining parts I've heard the "dpkg team" think are wild conjectures
on motivations and similar.

Or there's the following for example:

> IN particular, most systems are usrmerged today, and while these bugs
> are annoying, many people get along just fine.

That would imply that most people have either gone out of their way to
explicitly install and run usrmerge or they have reinstalled from
scratch. I cannot believe the first to be of any significance, the
second would put into question why we bother supporting release upgrades
(after all many other distros do not support that, we perhaps should
catch up with what the rest of the world is doing!).


I've also tried to stop replying to all misconceptions, inaccuracies
and plain wrong stuff on this thread (f.ex. people vocal in this thread
apparently do not exactly seem to know how upgrades or our package
manager works in Debian?), first to avoid dominating it with replies
(like some kind of deranged person, where I think I've probably already
surpassed my quota), and because it just all seems like a monumental
waste of time, energy and motivation. Which I'd rather spend elsewhere.



I'm personally just not seeing such consensus, despite the attempts of
some to make it pass as so. My perception is that this topic has become
such a black hole of despair, that people that take issue with it, are
simply stepping away.

Exhausted,
Guillem


Reply to: