[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]


On Mon, Feb 27, 2023 at 03:06:25PM -0700, Sam Hartman wrote:
> >>>>> "Steve" == Steve Langasek <vorlon@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

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

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


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/
slangasek@ubuntu.com                                     vorlon@debian.org

Attachment: signature.asc
Description: PGP signature

Reply to: