Bug#1060246: perl: proposed patch for perl ABI change due to 64-bit time_t

[Niko Tyni]

On Sun, Jan 21, 2024 at 09:41:26AM -0800, Steve Langasek wrote:
> On Tue, Jan 09, 2024 at 12:06:40AM +0200, Niko Tyni wrote:

> >   ifeq (s390x-linux-gnu,$(shell dpkg-architecture -qDEB_HOST_GNU_TYPE))
> >   perlabi = 5.18.2d
> >   else
> >   perlabi =
> >   endif
> 
> > as per https://salsa.debian.org/perl-team/interpreter/perl/-/commit/a66f196c13108b04909f9ec0e05986983cb2ed19
> 
> That's a very good point that I didn't think of, I'm +1 for doing it this
> way.

OK, great!

> > > This is entirely optional anyway, as perl
> > > 5.38 is just around the corner, at which point this patch should be dropped
> > > completely (assuming time_t lands before perl 5.38 does).
> > 
> > TBH I was hoping 5.38 would land first :)
> 
> And it has \o/
> 
> Do you want me to provide an updated patch, or will you integrate this on
> your side?

I'd like to understand the plan and expectations first. Apologies
if I'm just slow and this should all be obvious.

Do you want an upload to experimental with this right away? Or will
there be a set of source uploads switching the affected architectures
to 64-bit time_t at one point and this should be part of that? 

If you want it right away, perl will initially still use the 32-bit time_t
but declare it Provides perlapi-5.38.2-t64. Should it also Provide the
old perlapi-5.38.2 so that the affected (~500, mostly lib*-perl) binary
packages stay installable before they are rebuilt?

What about the libperl5.38 SONAME and package name? Is it OK for them
to stay unchanged? I expect the interpreter struct size changing will
affect the libperl ABI as well.

Will somebody else upload perl to sid on the flag day? Is that expected
to be a no-change upload of the version in experimental, or should there
be versioned build dependencies ensuring that time64 builds of libc,
libdb et al. get picked up?

Also wrt. the exact patch: now that we've established the perlapi name
change will be only be done for the affected architectures, I suppose I'll
need a list of those. Should the 32-bit archs on debian-ports be included?
Could I just use DEB_HOST_ARCH_BITS (except i386?)?

> > Failed 7 tests out of 2623, 99.73% okay.
> > 	../cpan/DB_File/t/db-btree.t
> > 	../cpan/DB_File/t/db-hash.t
> > 	../cpan/DB_File/t/db-recno.t
> > 	../cpan/DB_File/t/db-threads.t
> > 	../cpan/Memoize/t/errors.t
> > 	../cpan/Memoize/t/tie.t
> > 	porting/libperl.t
> 
> > but I guess that's because things like libdb5.3 need to be rebuilt first?
> 
> Sorry, haven't tried anything like this yet.  ABI skew with dependencies
> could certainly explain test suite failures!

I'm concerned that this may be a blocker on the flag day if not tackled
earlier. My intuition is the DB_File failures will probably go away
once libdb is built with 64-bit time, but I'm less optimistic about the
Memoize or libperl tests.

I'm also concerned that the binNMUs of the perlapi-* reverse dependencies
might FTBFS in sid with the 64-bit time_t change if not tested beforehand,
and in the worst case render much of sid uninstallable. Is the plan to
just put out any fires as they are spotted, and how much urgency will
there be at that point?

So many questions :) Many thanks for working on this.
-- 
Niko