Re: Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?
On Fri, Feb 22, 2019 at 11:20:24AM +0100, Didier 'OdyX' Raboud wrote:
> Thank you for the various comments. I have amended the ballot (which is more a
> "explanation text + short ballot" incorporating the suggestions from the IRC
> meeting as well as taking into accounts remarks on this bug.
Thanks for your work on this, and sorry for being so late to the party.
The summary is excellent IMO.
> * `weak`: both directory schemes are allowed, packages only built on classical
> hosts
> * `middle`: both directory schemes are allowed, packages can be built anywhere
> * `hard`: both directory schemes are allowed, packages only built on
> "merged `/usr`" hosts
[...]
> * B: The desireable solution at the time of bullseye is `hard`; both directory
> schemes should be allowed, and packages can be built on hosts with either
> classical or "merged-`/usr`" directory schemes.
Isn't this the 'middle' option above rather than 'hard'?
FWIW I think I'm OK with recommending 'middle' but 'hard' seems over
the top. Ideally there should be no difference in building on merged
/usr hosts vs. classical ones.
As for buster and overriding the debootstrap maintainers on the default:
I think being able to do local builds that work on other Debian
systems with minimal fuss (no chroots etc.) is a desirable property
but not an absolute requirement. I'd certainly love to see all the
'paths_vary_due_to_usrmerge' issues fixed for buster [1].
However, given the low number of affected packages I don't think
they are a good enough reason to have the TC override the debootstrap
maintainer decision. Documenting the remaining issues with local builds
on merged-/usr hosts and aiming to eliminate them for bullseye would be
enough IMO.
[1] help on #914128 in src:perl would be welcome
--
Niko Tyni ntyni@debian.org
Reply to: