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

[Steve Langasek]

Hi Niko,

My sincerest apologies for having failed to reply to this email for so long.

On Sat, Jan 27, 2024 at 12:50:40PM +0200, Niko Tyni wrote:
> > > > 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? 

So an experimental upload is of course no longer relevant.  And since we're
not changing package names, the rationale for the experimental uploads
didn't apply to perl, so that's fine.

> 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.

I had been assuming that changing it in the one place is sufficient because
the packages would be updated in lockstep, but I see there are a few
packages depending on the lib without also depending on perlapi:

$ grep-dctrl -n -sPackage -FDepends,Pre-Depends libperl5.38 -a \! -FDepends perlapi-5.38.2 /var/lib/apt/lists/*amd64*Packages | sort -u
barnowl
binkd
claws-mail-perl-filter
courier-mta
elinks
epic4
epic5
exim4-daemon-heavy
freeradius
gnumeric-plugins-extra
hexchat-perl
kamailio-perl-modules
kildclient
kvirc-modules
libfungw-perl1
libgrokj2k1
libperl-dev
libperl4caml-ocaml
libpolymake4.11
libsnmp40
mimedefang
nbdkit-plugin-perl
perl
postgresql-plperl-16
rxvt-unicode
slapd
uwsgi-plugin-psgi
vile
vim-gtk3
vim-motif
vim-nox
weechat-perl
xvile
znc-perl
$

Excluding perl itself it looks like that's 32 binary packages.  Compared
with the changes to perlapi, that seems like a trivial and manageable
transition, so +1 for changing the library name.

> 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?

Well, this hasn't happened but now I think it's urgent that it happens.  As
I mentioned on IRC, we're entangled with gdbm and db5.3 time_t transitions,
and we can't safely rebuild perl on armhf *without* bumping the ABI
declarations.

I can NMU this today if you want or I can leave it to you, please let me
know.

> 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?)?

There are some further refinements where some ports archs not in Debian do
not have an ABI change because they are natively 64-bit time_t.  And the ABI
does not change on either i386 or hurd-i386.  But I am not convinced this is
particularly important, it's just an extra round of binNMUs (among a flood
of binNMUs) for those ports, and binary compatibility with third-party debs
is not an issue (and particularly considering the perl ABI changes with each
major update so there is no binary compatibility with stable anyway).

> > > 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?

Yes we will be putting out fires as quickly as possible :)

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                   https://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/perl-maintainers/attachments/20240302/6f7e241e/attachment.sig>