Re: support for merged /usr in Debian
Florian Lohoff <f@zz.de> writes:
> On Sun, Jan 03, 2016 at 10:14:14AM -0800, Russ Allbery wrote:
>> No. Debian has basically given up on this; there are way too many
>> packages and way too much stuff that would have to be moved to /bin and
>> /lib in order to preserve the traditional semantics that allow /usr to
>> be mounted very late. I've poked a bit at this in the past, and the
>> amount of work that would be required is daunting, and benefits only a
>> few highly unusual edge cases.
> From my 25 year Unix experience i dont like the usr merge.
>From my 22 years of UNIX experience, I don't understand why you care. :)
Maybe something in those other three years was particularly enlightening?
I do understand why people working in the embedded space care about some
unusual mount orderings, file system separations, and very light cores,
and I hope that we can accomodate and support all of their use cases
inside Debian. I think that's the most productive part of this thread.
But I don't get why people who are using non-embedded UNIX systems
particularly care. If you've used UNIX for a long time, you've seen
binaries in all sorts of bizarre and irritating locations. This is minor
compared to the organizational differences between various commercial
UNIXes back in the day. I don't particularly care if we do it, and don't
particularly care if we don't do it, since neither the current state nor
the desired destination state seems likely to impact my life in any way.
If people feel like it would provide lots of benefits to them, I'm dubious
that anything is actually benefiting from the split /bin and /lib at this
point, and it would slightly reduce the cognitive load for everyone
maintaining packages if no one has to think about whether something should
go in /bin again.
If we had a system where /bin plus /lib plus /etc was a fully-working base
UNIX system that was entirely functional without /usr, and then /usr was a
properly-segregated set of supplemental programs, I can vaguely see why
maintaining that state could be useful. But, reality check: we *don't*,
and we haven't for *years* (if, in fact, we ever did). I'm sure that you
could cobble together some special cases that mostly worked this way, but
Debian as a project has never gotten this right.
The reason why is pretty obvious if you look at it as a software
engineering problem. You're asking all package maintainers (a huge set of
mostly-uncoordinated developers) to maintain a very subtle and careful
distinction (it's very inobvious to most people whether some specific
program should go into /bin or some specific library should go into /lib)
involving complex transitive dependencies (libraries you would never
expect to be part of "early boot" end up being runtime dependencies of
some tool that some init script needs to use). And, worse, this very
subtle and complex distinction is *never tested* and *almost untestable*
since even getting mistakes to actually fail requires setting up a very
unusual partitioning and mounting scheme and then exercising it in unusual
ways.
This is, to say the least, not a recipe for success.
Insofar as I have any agenda in this thread, it's that, with my Policy
editor hat on, I don't think we should be claiming we're maintaining
invariants that we actually aren't maintaining, and that, given a
realistic look at our coordination and testing capabilities, we aren't
going to maintain. That's just bad for everyone. People take us at our
word and then get upset when things don't work, some maintainers will put
in tons of painful work to try to support this because we say that we
support it, and that work will be mostly useless because other people
won't even be aware of the problem and will accidentally break it.
> As you sum up very nicely and i agree on is that Debian has given up on
> being slim at this point.
Maintaining a separate /bin and /lib has nothing to do with being slim.
Truly. They are completely unrelated.
Being slim is about keeping the essential and required set small and
tight. It makes no difference whatsoever to disk or memory utilization
whether things are installed in /usr/lib or in /lib.
> There is no such thing as a single user mode boot with only the rootfs
> anymore.
Yes, there is. The rootfs just includes /usr.
> PS: And i hate giving up on technical issues.
That's the whole thing, though. Maintaining a meaningful /bin and /lib
vs. /usr split is not primarily a technical issue. It's a coordination
issue. The technical work for a single package is painful only because
moving things is really painful. The problem is more that it affects
thousands of packages maintained by numerous different maintainers who are
never testing that configuration and may not even be aware that it exists.
You could possibly make it a technical issue if you developed
comprehensive test suites for the invariants that you feel we should
maintain that could report those results to the maintainers, similar to
Lintian and friends. That way at least it would be a testable problem,
and we could possibly build tools for managing things like moving binaries
into /bin when something else starts depending on it. But, please, before
you start working on that, think hard about whether the effort is actually
worth it.
Another word for "giving up" is "applying sane prioritization." We can't
fix every wishlist bug. Is this one actually worth the effort?
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: