Adam Borowski writes: > On Tue, Dec 04, 2018 at 06:48:45PM +0100, Ansgar Burchardt wrote: >> 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.
So only all? > We later learned only a part of the archive got rebuilt since the bad > debootstrap backport. Yes, some packages were not yet rebuilt in testing, but having them rebuilt in unstable is enough. >> 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... No, anyone using testing/unstable to setup a new build chroot since June should have gotten a merged-/usr chroot. That no issues were found earlier is probably related to there being not so many issues. (Fun fact: there are ~3k debootstrap installations on testing/unstable, compared to 6.2k on stable and 2k on oldstable according to popcon.) Anyway, buildds are not using merged-/usr, so there is no problem with them. > and the sky started falling immediately after that. Hmm, two packages or so were reported to be broken. That is a quite high standard for "sky falling". What would you call an upload that breaks more packages? The monthly apocalypse which we deal with just fine? >> 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). You keep saying that it is too late to fix anything or that it is too much work, but why do you think so? I've looked at patching packages and how many packages need changes and it does not seem much work; indeed after a week about half of the packages already have a (usually trivial) patch. If you think it is too much work or too many things break, please at least give an estimate of what you are talking about... I feel like only one side is doing any research here. > 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. If we keep merged-/usr as default then we can /recommend/ people to install usrmerge to switch to merged-/usr; reducing the difference between newly-installed and existing setups is a good idea IMHO. I think I filed a report for this two years ago. Maybe we should also mention somewhere that it might be useful to not switch build environments (yet). Ansgar