Dear Maintainer,

When installing the "new" package libaio1t64 package in Debian testing
or Ubuntu Noble, the previously available libaio.so.1 file/symlink is no
longer available. This effectively breaks non-debian built package like
for example the Oracle Instant client which would need a libaio.so.1
compat symlink to "work". This was for example reported in Oracle forums
here:
https://forums.oracle.com/ords/r/apexds/community/q?question=instant-client-on-ubuntu-24-04-noble-numbat-7244

I see that for #1067831 you added a compat symlink, but only for the
udeb package, and apparently in the dicussion the idea to add this
symlink in the base package rather the udeb one was ruled out. However
in practice it means third party binaries like the oracle ones are still
broken unless a symlink is manually created.

If there is really an issue with adding it in the package, can we at
least consider Raphael Hertzog's propsal to add it as a postinstall
step (checking if the libaio.so.1 exists and if not symlink it) ?

Thanks,
Romain

Hi!

In the Debian context this was intended to be a temporary
non-intrusive solution that would not stomp over upstream, until this
had been agreed with them. My intention has always been to revert the
local SONAME bump before the next Debian release. Ubuntu will have to
deal with this however best they see fit.

I was able to verify whether part of the Linux kernel fix I had in mind
solved the test suite issues (and were not caused by faulty libaio
changes), and have now submitted the libaio and Linux fixes upstream, at:

https://marc.info/?l=linux-aio&m=171745321208314

so ideally, if they agree with the API/ABI changes, I'd then revert
the SONAME transition in Debian and provide the t64 backwards compat
symlinks in the libaio1 package. Otherwise I'll work with upstream on
a suitable API/ABI change, and in that case I would not be able to
provide backwards compat symlinks.

Thanks,
Guillem

On Tue, 4 Jun 2024 00:44:13 +0200 Guillem Jover <guillem@debian.org> wrote:

I run testing and this bug also seems to affect grub2-common v2.12-5
which is still in testing and hasn't been upgraded yet.

The testing kernel was upgraded from 6.12.12 to 6.12.17 and subsequently
failed to boot my encrypted rootfs (decrypts ok but the mapper fails to
find the rootfs). Running upgrade-grub manually gets a complaint about
not finding libaio.so.1. If I manually make the symlink then update-grub
works and I can boot successfully.