Re: RFC: Reworking build flags — «*_FOR_BUILD» flags handling

Hi Guillem,

On Thu, Nov 30, 2023 at 01:17:37PM +0100, Guillem Jover wrote:
> [ See <https://lists.debian.org/debian-dpkg/2023/11/msg00031.html>. ]
> 
> This problem is related to the *_FOR_BUILD support (to specify flags for
> the build instead of host system during cross-building), which got
> recently partially improved (in dpkg 1.22.1), but there are still things
> not covered.
> 
> These are at least two of the sub-problems that need to be tackled:

I am not sure whether these problems actually need solving, but saying
this I may curse myself in some years. ;)

> * Need to make features per-arch in output (such as --query), but that
>   might break users not expecting repeated entries. I guess the options
>   here might be to either:
> 
>   a) try to look for users of the interfaces and make them cope (but
>      that would miss internal/private usage),
>      [ If starting from scratch I'd rather do this, but it has now
>        the potential for breakage. ]
>   b) version the interface via a CLI option,
>      [ This would be a general solution that would allow extensions in
>        the future, but complicates the interface. ]
>   c) add an explicit --for-build mode which would turn the output into
>      the *_FOR_BUILD features,
>      [ This is a targeted straightforward change, and a clear interface,
>        but it involves running the tool twice to get all the info. ]
>   d) or use different field keys for the paragraphs.
>      [ This is rather meh. ]

e) dpkg-architecture -a${DEB_BUILD_ARCH} -f -c dpkg-buildflags --query-feature $SOMEFEATURE

This is roughly the same as c) and works today.

>   None of which seem ideal (although some seem less desirable) TBH.
> 
> * Need to honor build features, either from DEB_BUILD_OPTIONS or a
>   new envvar (and finding a non-confusing name!), but probably only for
>   a few of the features where it might really make sense (such as abi,
>   qa, hardening.pie) and which might affect the buildability or
>   runability of the artifacts, as anything else seems unnecessary.
> 
>   I'm not certain about the envvar part, I think the last part is in
>   theory straightforward, the code just needs to duplicate the checks
>   per the various arches, and keep track of the various features per arch
>   internally, which might require breaking changes in the interfaces,
>   but I think the perl modules are not public interfaces anyway.

In general, using a different variable than DEB_BUILD_OPTIONS seems a
difficult sell to me. For instance, DEB_BUILD_OPTIONS=noopt affects
build and host and to me that seems vaguely sane. Beyond that, I concur
with there being little need for configurability here.

Maybe this is just me being unimaginative.

Helmut