Bug#914897: debating the wrong thing
Ian Jackson writes:
> Ansgar Burchardt writes ("Bug#914897: debating the wrong thing"):
>> Switching to (1) or (3a-with-no-support-in-buster) will mean merged-/usr
>> systems would no longer be supported. In this case someone would have
>> to write a unusrmerge program to convert systems with merged-/usr to
>> systems with unmerged-/usr.
>
> Currently merged-usr is broken because it can build packages which do
> not work on non-merged-usr systems.
In very rare cases (an estimated 0.3% of the archive or so). I'm fairly
confident that for more than 0.3% of the archive something can go wrong
when building in non-clean environments.
> It would be quite wrong (both technically and socially) to react to
> this lack of foresight,
The reported problems are not really unexpected...
> lack of consultation,
It was discussed on -devel@ several times. I think LWN also reported
about merged-/usr developments in Debian more than once, it wasn't a
secret cabal development.
So where is the lack of consultation?
> and lack of testing, by pressing forward.
It has been tested for quite a while.
A helpful new test was recently added by the Reproducible Builds project
which allowed to identify most problematic packages.
What is technically and socially wrong is reverting a change after a
small issue was found which is already in the process of getting fixed
for most packages.
> When we have stopped generating more lossage, we can start to think
> about whether we want to transition to usrmerge as default, whether to
> make it mandatory, and if so how the transition should be handled, and
> on what timescale.
We had the discussion (usrmerge as default) already quite some time
ago. Why start again at zero? As a random reference, the D-I Stretch
RC 1 release announcement explicitly stated:
+---
| * The switch to merged-/usr as the default setting for debootstrap
| was reverted since it uncovered a number of important issues which
| might not be all fixed in time for stretch. This setting is
| expected to come back as the default at the beginning of the next
| release cycle.
+---
And just that happened (except a bit later).
You could have easily asked the tech-ctte back then (or even before)
instead of waiting until shortly before the Buster freeze and after
people invested more work.
Making it mandatory or not is an unrelated decision. That can easily
just come later.
> We need the space to discuss those options properly without being
> distracted by what is IMO currently a crisis in stretch-backports and
> buster.
There is no such crisis. There was also enough time to discuss this in
the last years or even since June (when it was enabled by default
again)...
Ansgar
Reply to: