On Fri, Nov 09, 2018 at 12:26:15PM +0000, Simon McVittie wrote: > On Fri, 09 Nov 2018 at 06:31:00 +0000, Niels Thykier wrote: > > As I understand it, what this question effectively ends up being is "Do > > we commit to supporting merged-/usr in Buster in all source packages > > (making such bugs RC) OR do we rollback the default merged-/usr in > > debootstrap (making them non-RC)?". > > Well, there's a middle ground, which I think would be a good short > term plan: we can ensure that the official buildds build packages in a > non-merged-/usr environment (for example by backporting a fix for #913228 > to the packages used on those buildds), which means misbuilt binary > packages uploaded by maintainers remain potentially RC (as systemd's > #843433 was), but source packages that would theoretically be misbuilt > in a merged-/usr environment (like quilt #913226) don't necessarily have > to be treated as RC. >...
This would be a huge regression, buildds aren't the only place where packages get built. It doesn't sounds right that we suddenly start declaring it "misbuilt" when a user builds a package locally with dpkg-buildpackage as has been working for the past 25 years. I am not aware of any real benefits of merged /usr for users, so let's go back from "How can we mitigate some regressions of merged /usr?" to "Can we make merged /usr working in buster without causing any regressions at all?". Either we fully support merged /usr everywhere, or merged /usr should not be supported in buster and the usrmerge package removed from buster as has been done in #863965 for stretch. > smcv cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed