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.
Now, it's entirely valid to trade off long-term complexity (unmerged
/usr) against short-term complexity (applying the /usr merge); one
possible answer to whether we should eliminate some unnecessary long-term
complexity is "yes, but not yet" (and the reason for this entire thread is
that part of the transition happened in the wrong order, with buildd and
pbuilder chroots becoming merged-/usr sooner than they should have done).
If I was wrong in assuming good faith and you were being argumentative for
the sake of being argumentative, please stop: that is not constructive.
Either way, please don't call me stupid. That is not *at all*
constructive - especially if you want things you say in future to change
my opinion on anything! - and contributes to an atmosphere of hostility
that drives away Debian contributors.
smcv
