On Fri, Feb 09, 2024 at 09:16:00PM +0100, Ansgar wrote:
> Package: debian-policy
> Version: 4.6.2.0
> Severity: important
>
> Hi,
>
> 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.
> 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.
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.
> 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.
dpkg-buildflags leads to build flags which are significantly different from
upstream, that have not been tested by users building from source, and they
can change without notice. It is very reasonable not to trust them.
In general we discourage diverging from upstream for similar reasons.
I offered #724621 as an option which would let packages maintainers control
which buildflags are used while still providing the benefit of buildflags.
Cheers,
--
Bill. <ballo...@debian.org>
Imagine a large red swirl here.
