Bug#1063605: debian-policy: mandate use of `dpkg-buildflags` for all software compilation on Debian

[Ansgar <ansgar@debian.org>]

On Fri, 2024-02-09 at 22:01 +0100, Bill Allombert wrote:

On Fri, Feb 09, 2024 at 09:16:00PM +0100, Ansgar wrote:

with the upcoming time_t & friends 64-bit transition, dpkg-buildflags

will be used to configure the ABI in use.

This decision comes from the wrong premise that the use of dpkg-buildflags

is universal, which is not the case. Hence it needs to be reconsidered.

There is not magic that will make all packages use dpkg-buildflags consistently

in the timeframe of this migration.

If packages do not use dpkg-buildflags, but use any ABI changed by the transititon, they will just be broken and must already be fixed.

 Thus all compiler

invocations *must* use the flags specified by dpkg-buildflags to avoid

ABI inconsistencies like this one:

  struct T { time_t a; time_t b; };

If this struct is accessed from both `libfoo1t64` (built respecting

dpkg-buildflags and thus time_t is 64-bit) and `bar` (built by a user

invoking gcc themselves), the result is probably not what one wants.

Thus `dpkg-buildflags` *must* be used by all packages *and* all users,

including users building their own software.  There is one exception

when libraries provide both 32-bit and 64-bit time_t ABIs like glibc

itself (but I doubt there are many of those).

No, it is required that packages use correctly the right compiler flags.

The interface for the compiler flags is dpkg-buildflags. See the transition annoucnement.

I did not come up with this interface, but am not aware of an alternative.

(C++ ABI changes were handled differently, but this transition did choose a different way; I'm not aware of the details why.)

Since packages need to be reuploaded anyway this is not a real issue.

dpkg-buildflags is not required for that, and does not necessarily achieve it

either, since upstream build system might not honor the environment variables

CFLAGS  etc. consistently.

Packages must ensure that these flags are passed correctly to the upstream build system. As mentioned above, any package not doing so is already broken (or will be by the transition).

Any compiler invocation missing these *should* be a serious bug.

(This should probably be mentioned in user documentation as well.)

This a different issue than mandating dpkg-buildflags.

You can also establish another interface, but currently the only one I'm aware of is dpkg-buildflags.

Ansgar