Re: Changes to abi=+time64 behavior (was Re: 64-bit time_t transition in progress)

[Peter Green]

So when introducing a new soname (no just a new package name), then one
should move to time64 even on i386 ?


The problem with doing this is that

1. A reverse dependency may depend on more than one library that uses time_t
   in it's API. Said reverse dependency would not be able to be sanely built
   if libfoo uses 32-bit time_t in it's API and libbar uses 64-bit time_t in
   it's API.
2. If any of your reverse dependencies are libraries that expose time_t in
   their API they would have a similar problem.

Re: Changes to abi=+time64 behavior (was Re: 64-bit time_t transition in progress)

[Bill Allombert]

On Fri, Feb 09, 2024 at 05:36:53PM +0100, Ansgar wrote:
> Hi,
> 
> On Fri, 2024-02-09 at 15:24 +, Bill Allombert wrote:
> > when introducing a new soname (no just a new package name), then one
> > should move to time64 even on i386 ?
> 
> If you know all consumers of the package will be using appropriate
> compiler flags to get 64-bit time_t, then this is fine.
> 
> Otherwise provider and consumer would disagree about ABI and likely not
> work fully correct.
> 
> > But fundamentally, how do we know how third-party binaries are
> > compiled ?
> 
> They have to use `dpkg-buildflags` with equivalent ABI settings.

Third-party binaries might not be build on a Debian-based distro...

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Re: Changes to abi=+time64 behavior (was Re: 64-bit time_t transition in progress)

[Ansgar]

Hi,

On Fri, 2024-02-09 at 15:24 +, Bill Allombert wrote:
> when introducing a new soname (no just a new package name), then one
> should move to time64 even on i386 ?

If you know all consumers of the package will be using appropriate
compiler flags to get 64-bit time_t, then this is fine.

Otherwise provider and consumer would disagree about ABI and likely not
work fully correct.

> But fundamentally, how do we know how third-party binaries are
> compiled ?

They have to use `dpkg-buildflags` with equivalent ABI settings.

Ansgar

Re: Changes to abi=+time64 behavior (was Re: 64-bit time_t transition in progress)

[Simon McVittie]

On Fri, 09 Feb 2024 at 15:24:50 +, Bill Allombert wrote:
> But fundamentally, how do we know how third-party binaries
> are compiled ?

We don't, but we can make some inferences.

If they are i386 binaries that already worked on Debian 12 or older,
and they call into time_t-sensitive ABIs (for instance X509_cmp_time()
in OpenSSL might be a good example), then they must have been compiled
with the expectation that time_t was 32-bit, because that's the ABI that
Debian 12 provided.

If they didn't already work on Debian 12 or older, then it isn't a
regression that they also don't work on Debian 13.

smcv

Re: Changes to abi=+time64 behavior (was Re: 64-bit time_t transition in progress)

[Bill Allombert]

Le Fri, Feb 09, 2024 at 10:20:40AM +, Simon McVittie a écrit :
> On Fri, 09 Feb 2024 at 05:03:23 +0100, Guillem Jover wrote:
> > if the maintainer
> > has requested it explicitly via DEB_BUILD_OPTIONS=abi=+time64, then
> > it should enable it also on i386 (changed behavior).
> > 
> > The reason is that this does not now break ABI for any package (in Debian
> > or out of Debian) that might have already opted-in to that feature, it
> > does not require adding all the necessary flags manually if one wants
> > to opt-in on i386, and makes it possible to selectively enable time64
> > on [non-library] packages where the binary backwards compatibility make
> > no sense
> 
> I think this is a good improvement. Another advantage of this change is
> that libraries that use time_t internally, but have been confirmed not to
> break ABI when it's enabled and don't call time_t APIs in their non-glibc
> dependencies, can easily opt-in to enabling it on i386 too. Some do this
> upstream already (like dbus and libsdl3 in experimental) but many don't.
> 
> To put this another way, the argument for not doing the transition to
> time64-everywhere on i386 was "we don't want to break third-party i386
> binaries", but ideally we should still be enabling time64, even on i386,
> in the cases where it *won't* break third-party binaries.

So when introducing a new soname (no just a new package name), then one
should move to time64 even on i386 ?
But fundamentally, how do we know how third-party binaries are compiled ?

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Re: Changes to abi=+time64 behavior (was Re: 64-bit time_t transition in progress)

[Simon McVittie]

On Fri, 09 Feb 2024 at 05:03:23 +0100, Guillem Jover wrote:
> if the maintainer
> has requested it explicitly via DEB_BUILD_OPTIONS=abi=+time64, then
> it should enable it also on i386 (changed behavior).
> 
> The reason is that this does not now break ABI for any package (in Debian
> or out of Debian) that might have already opted-in to that feature, it
> does not require adding all the necessary flags manually if one wants
> to opt-in on i386, and makes it possible to selectively enable time64
> on [non-library] packages where the binary backwards compatibility make
> no sense

I think this is a good improvement. Another advantage of this change is
that libraries that use time_t internally, but have been confirmed not to
break ABI when it's enabled and don't call time_t APIs in their non-glibc
dependencies, can easily opt-in to enabling it on i386 too. Some do this
upstream already (like dbus and libsdl3 in experimental) but many don't.

To put this another way, the argument for not doing the transition to
time64-everywhere on i386 was "we don't want to break third-party i386
binaries", but ideally we should still be enabling time64, even on i386,
in the cases where it *won't* break third-party binaries.

smcv

Changes to abi=+time64 behavior (was Re: 64-bit time_t transition in progress)

[Guillem Jover]

Hi!

On Fri, 2024-02-02 at 08:21:57 -0800, Steve Langasek wrote:
> Once all of these packages have built in experimental and we have identified
> and addressed all adverse interactions with the usrmerge transition, the
> plan is:
> 
>  - dpkg uploaded to unstable with abi=time64 enabled by default[5]

> [5] https://bugs.debian.org/1037136

I just realized recently that I think it'd be better to change a bit
the semantics of the abi time64 feature on i386, where by default it
will not include the time64 flags (as before), but if the maintainer
has requested it explicitly via DEB_BUILD_OPTIONS=abi=+time64, then
it should enable it also on i386 (changed behavior).

The reason is that this does not now break ABI for any package (in Debian
or out of Debian) that might have already opted-in to that feature, it
does not require adding all the necessary flags manually if one wants
to opt-in on i386, and makes it possible to selectively enable time64
on packages where the binary backwards compatibility make no sense
(such as dpkg itself, where this has already been requested and where
I mentioned in the libselinux report that I'd like to do that, and
where otherwise the port might be unable to install stuff at all).
Otherwise the majority of packages should have no need to explicitly
declare abi=+time64 as that's going to be the default (except for i386).

I've queued these updated semantics, including manual page updates and
unit tests into the next/time64 branch

(the previous semantics and incomplete commits are still in the
next/time64-default branch), which I'd be merging into main close to
the release, once there's agreement on the dpkg upload date.

If someone has issue with this, let me know and we can discuss the
merits of going some other way.

Thanks,
Guillem