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/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature
