On Tue, Nov 27, 2018 at 12:57:38PM +0000, Ian Jackson wrote: > > In the case of unmerged /usr, the only benefits I'm aware of for the more > > complex case (unmerged /usr) are circular: existing Debian installations > > have it, so switching to merged /usr is a change; > I think this is true for Debian itself now that we have bitten the > bullet of requiring /usr to be mounted along with /, early during > boot. (For the record I think that was a good decision.) > Unmerged /usr could have continuing benefits for Debian derivatives > who have avoided requiring early mounting of /usr. IDK whether such > derivatives exist. They could do, if they support a narrower range of > approaches to storage access than Debian proper. If such derivatives > exist then Debian adopting merged /usr would be likely to cause > problems for them, as we would introduce changes in Debian which would > be bugs in those derivatives. I don't know how serious a problem that > would be. Support for such a configuration is actively bitrotting as we speak. Library dependencies of /bin and /sbin are no longer isolated in /lib; udev will not reliably set up all devices without access to programs under /usr. Even if some derivative based on a recent Debian release has managed to keep usr-on-separate-partition-without-initramfs working for their purposes, this is not sensibly maintainable over the longer term, and the existence of such a derivative should carry very little weight with Debian when deciding whether to merge /usr. Example: even *without* merged /usr, an entirely sensible course of action for any maintainer of a Debian library package is to undo all special casing of /lib vs. /usr/lib in their debian/rules (.so -dev symlinks vs. runtime libraries, etc) and ship everything in /usr/lib, because the maintainer can rely on /usr/lib always being available. > I think it would be good to hear from any derivatives in this > position. We should probably ask them more formally than by having a > horrible flamewar on -devel: ie, in a way that invites the expression > of concerns and which reassures people that they will not be flamed or > dismissed. That would satisfy what I see as our social duty to > consult our downstreams. And if we did that and didn't get replies, > that might give us confidence that such derivatives don't exist. So > we could go ahead with a clear conscience. I don't agree that there's a social duty to consult downstreams that have made self-evidently poor engineering decisions, before making a change that will inconvenience them solely as a result of those same poor decisions. I don't mean that I'm unsympathetic to downstreams in that situation, or that I wouldn't want to help them; only that their plight /should not/ be an obstacle to Debian doing the right thing. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: PGP signature