Re: MichaIng > > The weird thing about the t64 transition is that is excludes i386, > > which stays on 32-bit time. > > You are right, the i386 *t64 packages contain "Provides:" for the non-t64 > package as well, like 64-bit arch packages. We do not deal with i386 at all, > so I only know this affecting armhf, and from the logic of Year 2038 > solution via time64 syscalls, I assumed it would be the case for all 32-bit > architecture.
Oh sorry, I somehow read your mail as concerning i386, but you didn't say that anywhere. (Though not "armhf" either.) Yes on armhf, upgrading postgresql-15 to postgresql-17 is a disruptive action for bookworm -> trixie. Thanks to the transition that was done to keep that (now single) architecture alive... > Thanks, that sounds like a solution I was looking for. Might be an idea to > implement this into the maintainer scripts as well for armhf, to prevent > users from being stuck with PostgreSQL 17 but v15 clusters? I mean sure, one > should have a backup etc. We will implement and test pg_dumpall + restore > for our users. If this works, I could open a PR to patch v15 and v17 > maintainer scripts accordingly. The maintainer scripts have learned about automatic upgrades for the easy cases only now, it was always manual before. I don't think retroactively patching for that extra case now is sensible - it also needs a lot of disk space, which is probably not available (and even if it was, it might not be in the location where the dump would be put by default). The next trixie->forky upgrade should work normal again (and will have automatic upgrades). > Among our ~140.000 users, mostly but not only SBCs, even that we do all we > can to have users on 64-bit userland where possible, we still have ~15% > 32-bit systems, mostly older Raspberry Pi models, and some Odroids. It's a valid option to keep using bookworm on old systems. Christoph
