Max Maischein

Crossposted from my blog

My upgrade of my home server from Debian 11 ("bullseye") to Debian 12 ("bookworm") went almost without a hitch. Yesterday I realized that the Postgres data hadn't been migrated from the old DB to the Debian package of Postgres 15. But luckily, the good Pg people provide a Debian package of 9.6 (the version which held my data) for Debian 12. I could install that one, fire it up, dump all data into SQL, fire up Pg 15 from Debian and import it there. Now I run such an SQL dump daily, just to have the data available as SQL files.

I wonder if it would be worthwhile for Perl to provide prebuilt binaries/packages of old Perl versions for current OSes, but then, there are so many build options that it's not worth the effort in general.

The only use case I see would be to provide an emergency Perl when your dist-upgrade nuked the system Perl [^1] , but some custom XS modules or XS modules installed via cpan instead of the package manager relied on that version. This would reduce the number of build options, but I'm still not sure if that actually helps anybody.

Maybe simply taking the (Debian) build files for old packages/distributions and running them for new distributions, with a prefix of /opt/perl5-xx could already help. People would still need to edit the path of their scripts to bring things back up.

This only makes sense when also rebuilding all the old CPAN modules for the new OS version, except under /opt. That's a lot of effort for little to no gain, except when people really need it.

[^1] : well, not nuked, but replaced with a newer major version that is not binary compatible