Re: 64-bit time_t transition for 32-bit archs: a proposal

[Guillem Jover <guillem@debian.org>]

On Tue, 2023-06-13 at 21:41:50 -0700, Steve Langasek wrote:
> After thinking about it, I'd like to suggest the following approach.
> 
> - dpkg with the new default behavior uploaded to experimental
> - libraries uploaded to experimental with the new package names (so, NEW
>   processing gets done) and with a versioned build-dependency (easy to
>   automate with sed on debian/control)
> - once all the libraries have cleared NEW, copy to unstable without dropping
>   the versioned build-dependency; it will never be wrong, it will always at
>   most be cruft that can be cleaned up lazily
> 
> What do you think?

Yeah, sounds good to me.

> On Thu, Jun 08, 2023 at 04:06:08AM +0200, Guillem Jover wrote:
> > On Mon, 2023-05-22 at 18:17:44 -0700, Steve Langasek wrote:
> > > > Hmm, rechecking the script, I think we'd want to at least
> > > > unconditionally add the Breaks and Replaces (no need for substvars
> > > > then), otherwise we'd get upgrade errors?
> 
> > > > That would leave only the Provides as potentially conditional…
> 
> > > You're absolutely right, thanks for catching this!  Fixed in git.
> 
> > As hinted above, I think the source:Version substvar should be
> > switched to a hardcoded version at the point the migration was done,
> > otherwise it will be floating forward and not catch older affected
> > versions?
> 
> Oh ok, I didn't catch that this is what you meant.  But it's not clear to me
> what you mean by "not catch older affected versions" - why would it be wrong
> to Breaks/Replaces against non-existent, newer versions of an obsolete
> binary package name?

Err, sorry right, that paragraph didn't make much sense, I think I might
have lost context between the first time I checked this and the next. :)

> It's not a difficult change to make, I just don't understand why it's
> important.

Rereading my own comment, I think what I might have been thinking about
was that the version restrictions do not make much sense, and would not
protect against potential reintroduction of those obsolete package
(probably not in Debian but elsewhere). So probably not important in
the Debian context, but it would seem more correct and future-proof to
me to completely drop the version restrictions?

> > Just to try to understand whether we are on the same page. If these
> > libraries have no time_t usage at all, then disabling time64 should
> > then provoke no time_t issue and should stop implicitly enabling LFS.
> > But if the library contains internal time_t usage that is not part of
> > the exposed ABI, but part of its operation, then I'm not sure I see
> > how we can patch them to disable LFS w/o at the same time losing
> > time64 support (as the latter forces/requires the former).
> 
> > I'm not sure whether you are talking about the first or second case?
> > And whether we have no libraries at all falling under the second case?
> 
> I was only thinking about the first case, I had not previously considered
> the second case.  We should be able to determine fairly easily whether there
> are any in the second case; for all ELF binaries which are built from the
> same source package as an LFS-sensitive library, check whether they have
> references to any of the static list of symbols in glibc that are affected
> by time_t, and if they are, add them to the list of libraries to transition.
> 
> I'll add this to the analysis in progress.

Perfect, thanks!

Regards,
Guillem