Bug#913229: release.debian.org: RC status of merged-/usr bugs?
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
Reply to: