Bug#914897: debating the wrong thing
On Tue, Dec 04, 2018 at 06:48:45PM +0100, Ansgar Burchardt wrote:
> 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.
Your figure of ~80 packages counts only packages which went through a
reproducible-builds rebuild. We later learned only a part of the archive
got rebuilt since the bad debootstrap backport.
> 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.
Making packages with non-Debian origin randomly break is not a "small
issue". Remember, we can fix only packages we make ourselves -- not any of
private/PPA/company-wide packages so many of our users make.
> > 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).
Except that the change went live only on 2018-11-10, then waited until
buildds recreated their chroots, then until dinstall and mirror push...
and the sky started falling immediately after that.
We train DDs to not upload packages built in an unclean environment -- I
made ~1000 uploads (mostly sponsored) which did not include a _single_
unclean build. I expect most DDs to be alike, and most of us also do
source-only except to NEW.
We tend to build outside a chroot only during development. Of course we do
test those packages but almost always on the same machine we're sitting at.
Which happens to match the usrmerge status of the package being tested...
> 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.
It was only shortly before the Buster freeze that we saw this change in
action! Had the switch get flipped sooner we'd have a chance to see the
results. By now, it's much too late to fix things before the freeze
(and I don't see how they could be fixed even had we two years of time).
> 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)...
Nope, it got enabled very recently. This is a case where religiously
building stuff in a clean environment bit us -- because _that_ environment
wasn't changed.
By now, all we can do is damage control. Which can be a hasty force-merge
or a hasty revert. Unless you can somehow make dpkg-dev omniscient.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Ivan was a worldly man: born in St. Petersburg, raised in
⢿⡄⠘⠷⠚⠋⠀ Petrograd, lived most of his life in Leningrad, then returned
⠈⠳⣄⠀⠀⠀⠀ to the city of his birth to die.
Reply to: