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

[Niko Tyni]

On Sat, Mar 02, 2024 at 11:51:16AM -0800, Steve Langasek wrote:
> My sincerest apologies for having failed to reply to this email for so long.

Thanks, appreciated.

> On Sat, Jan 27, 2024 at 12:50:40PM +0200, Niko Tyni wrote:

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

Yes. The packages linking against libperl5.38 are typically programs
that embed a Perl interpreter. OTOH the packages depending on perlapi-*
provide Perl plugins (= loadable binary Perl modules). These two are
somewhat orthogonal things.

It's not clear to me if the perl interpreter structure size change
changes the libperl ABI, but that seems probable. Anyway I agree it's
better to err on the safe side.

As you've noticed, the libperl package name change is not quite trivial.
I don't think we've done that in the past except with full upstream
version changes so there might be some sharp edges. I'm sorry about that.

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

As I already told Julian a few days ago on this bug, any necessary NMUs
are welcome. Given the urgency we've ended up with, I'd prefer you do
the upload and take responsibility for any bugs possibly introduced.

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

Thanks again for your work on this.
-- 
Niko