On Mon, Feb 27, 2023 at 03:06:25PM -0700, Sam Hartman wrote: > >>>>> "Steve" == Steve Langasek <vor...@debian.org> writes: > Steve> If this is for people doing out-of-archive builds who don't > Steve> want to deal with failures from -Werror, I can see how having > Steve> a single environment toggle is useful to them; but it doesn't > Steve> seem useful to *Debian* when such out-of-archive rebuilds > Steve> don't correspond to the official builds. E.g. if they're > Steve> test builds for new toolchains, knowing that the package > Steve> *could* build, with options Debian doesn't actually use, is > Steve> of limited use. (If you build twice, once with once without > Steve> and file bugs on packages where the results differ, I guess > Steve> that's one use, but involves a lot of manual labor.)
> In the general case I agree. > But we have the specific case of cross-bootstrapping. > They want to be able to do builds to bootstrap and they want to have an > option they can pass into the build to ask debian/rules not to include > -Werror. > I suspect Helmut believes he can get patches accepted in the packages > where this is most important to honor the option. > Given his track record, I bet he's right. > So, we have a team in Debian wanting a interface sufficiently > standardized for them to do their work. > I think we have confidence that once we agree on a interface they can > produce appropriate consumers of the interface as well as > implementations of the interface. > I think we should have a high bar for standing in the way of this kind > of work. Well, I'm not seeking to stand in the way of the work, so much as trying to make sure this is the most useful work to be doing to meet the actual use cases. I can see that for bootstrapping a new architecture, it will sometimes be useful to use a toolchain newer than the one that is currently default in Debian, and as a result it is useful to also be able to bypass new stricter -Werror behavior from gcc upstream that breaks compatibility with existing code. It isn't clear to me from the discussion history that this is the actual use case at issue. But supposing it is, that's one use case; and it's a use case that can be addressed without having to make any per-package changes and without having to make any changes to dpkg-buildflags interfaces by exporting DEB_CFLAGS_APPEND=-Wno-error DEB_CXXFLAGS_APPEND=-Wno-error as part of the bootstrap build environment, for all packages. Of course, dpkg-buildflags also exports flags for other languages than C and C++ (and should do), so if you want to have full package coverage you would want your set of _APPEND variables to match the set of per-language flags that dpkg-buildflags already handles. Having to export 7 variables instead of 1 is annoying. But it also doesn't require reaching consensus on a new interface in dpkg. And I remain unconvinced that the particular proposed interface is the right way around for Debian at large. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature
