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

Re: usrmerge -- plan B?

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.

Scott Leggett.

Attachment: signature.asc
Description: PGP signature

Reply to: