fix time64 package rename in debian 13 for libssl3

[HB9HIL]

similar issue as in #1247

Ref:

• https://packages.debian.org/trixie/i386/libssl3t64/filelist for 32bit systems also available
• https://packages.debian.org/search?searchon=names&keywords=libssl3

[mlocati]

As described here, we'd need to test some extensions that use libssl.

For example, in order to test the zip PHP extension (which uses $buildRequiredPackageLists_libssl) you could push an empty commit created with:

git commit --allow-empty -m "Empty commit" -m "Test: zip"

[HB9HIL]

Testing zip, memcached, curl, imap
What else do you want me to test?

As described here

Sorry 😁 forgot about that.

Not sure if this failed test related to my change.. previus run passed

Maybe you can rerun the failed tests

[HB9HIL]

Yep there is definitly something not working as it should be on docker.io 😆 but tests are good as it looks like

[mlocati]

It was a transient issue: I relaunched the tests and they passed.

👍

[mlocati]

Why (t64)? and not just t64 ?

[HB9HIL]

Why (t64)? and not just t64 ?

(t64)? is more tolerant and still works if only libssl3 is available even on deb13 (for whatever reason). So it works for both. Better safe than sorry.

If you want me to make it hard t64 I can change it.

[HB9HIL]

PS: in theory we could also omit the debian 13 check and just go with (t64)?. But this wouldn't match the other packages and logic of the script. Feels just more safe to go with the deb13 check

[mlocati]

What happens if we have both packages (the one with t64 and the one without t64)?

[HB9HIL]

What happens if we have both packages (the one with t64 and the one without t64)?

if both packages libssl3 and libssl3t64 would be available from package source, both would get installed and marked as dependency. this works as long both package can coexist on debian 13 and not throw a conflict. This is likely not the case as if debian 13 decides to bring back libssl3 for compatibility reasons (I doubt this happens), this will only a symlink

So it's a question "either / or" here. Secure in case both packages exist (using (t64)? regex) or hardcoded t64 so we know that it never changes. You decide :)

[HB9HIL]

root@lab0:~# apt install libssl3
Note, selecting 'libssl3t64' instead of 'libssl3'
Upgrading:
  libssl3t64  openssl  openssl-provider-legacy

Summary:
  Upgrading: 3, Installing: 0, Removing: 0, Not Upgrading: 105
  Download size: 4,263 kB
  Space needed: 13.3 kB / 10.2 GB available

Continue? [Y/n] n
Abort.
root@lab0:~# cat /etc/debian_version
13.4

libssl3 is currently a virtual package on Debian 13.x. So both packages can't be available. Also, on the next SONAME dump, like libssl4, the t64 will be removed again. So the regex would be more safe in this case.

[mlocati]

If installing libssl3 is the same as installing libssl3t64, do we really need this PR?

[HB9HIL]

If installing libssl3 is the same as installing libssl3t64, do we really need this PR?

Well currently it fails. Don't ask me why only for armv7 but it fails because of the naming 😄

[HB9HIL]

If you are interested in the full log

https://github.com/HB9HIL/wavelog/actions/runs/27264993932/job/80520398406

[mlocati]

Thanks for the feedback! So, let's keep the (t64)? approach