On 2018-11-27.08:54, Simon McVittie wrote: > On Tue, 27 Nov 2018 at 09:18:08 +0100, Stephan Seitz wrote: > > But I don’t want to get the /usr-merge forced upon my systems because this > > minority is obviously too stupid to install the package and migrate their > > systems on their own. > > That would be a terrible justification for merged /usr, but it is also > not a justification that anyone is using. In the interests of assuming > good faith, I'll assume that you have missed the messages that describe > why applying merged /usr to all Debian systems might be a good idea, and > attempt to summarize them. > > I hope we can agree that unnecessary complexity is technical debt, but > necessary complexity is necessary: if complexity exists for a reason, > then the "cost" of the complexity should be compared with the benefit > of having it, to decide whether the complexity needs to be kept. > > Merged /usr is a simplification. It takes a few classes of bugs - > most obviously "a package refers to a command by its absolute path in > /usr/bin, but really it's in /bin, so that won't work" and its opposite - > and makes them disappear. > > 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; and if build systems > have unmerged /usr, then it's a lot more straightforward for packages to > find the canonical paths of programs (such as the fact that it's /bin/sh > and /usr/bin/perl, not the other way round), and packages sometimes > need to know the canonical paths of programs so that the package will > continue to work on unmerged /usr systems. If all systems were merged > /usr, then there would be no reason why packages would need to know that > sh is in /bin but perl is in /usr/bin, because both executables would > (effectively) be in both places. So *all* systems being merged-/usr would, > again, be a simplification.
Thanks for your multiple thoughtful and detailed contributions to this discussion. They are greatly appreciated. -- Regards, Scott Leggett.
signature.asc
Description: PGP signature
