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 (r...@debian.org) <http://www.eyrie.org/~eagle/>