Ubuntu noble is missing libaio.so.1 compat symlink

[Romain Geissler]

Hi,

Would it be possible to backport this creation of a compat symlink libaio.so.1 in noble please: https://git.launchpad.net/ubuntu/+source/libaio/commit/?h=applied/ubuntu/devel&id=e0165fd654888dac2677dfdca3a67e9c56ebcb7c

Third party tools depending on libaio, like typically Oracle Instance Client, will need libaio.so.1, and apparently the t64 change is binary compatible with that (as written in the commit message). It causes issues like described in the Oracle forums: https://forums.oracle.com/ords/apexds/post/instant-client-on-ubuntu-24-04-noble-numbat-7244

Thanks,
Romain

[Romain Geissler (rgeissler-1a)]

Actually it's not needed in the udeb package, but in the normal libaio1t64 package.

[Paride Legovini (paride)]

Hello and thanks for this bug report. The SONAME bump has been done deliberately, see this changelog entry (from version 0.3.113-6):

- Perform a SONAME bump to avoid stomping on upstream SONAME. Once and if
  the new symbols are accepted by upstream then we can merge that back
  into libaio.so.1 and drop the t64 packages and temporarily provide
  a compat symlink for the t64 SONAME for a smooth transition back. This
  should also be an easier way to revert this transition when there are
  no file conflicts involved, and does not block on upstream support.

I didn't go into the details of the problem, but I doubt the compatibility symlink can be added as it would potentially cause the "stomping on upstream SONAME" that the package maintainer wants to avoid.

If you still believe this can be done, I suggest filing a bug against the libaio Debian package:

  https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=libaio

as the Ubuntu package is currently a sync from Debian, and this kind of issue is better fixed upstream (= in Debian) when possible.

I'm marking this as Incomplete for now, but if you agree this won't be fixed as suggested, please mark this bug as a Wontfix. Thanks!

[Romain Geissler (rgeissler-1a)]

For me adding the symlink will not create issues with the SONAME bump, old binaries (ie which were not relinked) will use libaio.so.1 while newly linked binaries will use the new soname libaio.so.1t64 as the package maintainers expects.

I have re-started the conversation in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1072471 as it seems I am definitely not the first raising the exact same problem with oracle instant client binaries.

[Sascha Lucas (sascha-lucas)]

The Debian Maintainer said[1]:

"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'm hereby marking this bug to Confirmed in Ubuntu.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1072471#10

[Sergio Durigan Junior (sergiodj)]

Thanks for providing additional information.

Let me take a step back and see if I understood the problem.

- Oracle Instance Client links against libaio.so.1

- As part of the time_t 64-bit transition on Noble, we renamed several of our libraries and appended "t64" to their names.

- Debian decided to perform an SONAME bump in order to avoid some problems with upstream. Oracle Instance Client can't find the new library, and needs to be recompiled.

I tend to agree with Paride here that we probably shouldn't ship a symlink in this case. Moreover, it seems to me that this is actually a bug with Oracle Instance Client: it needs to be rebuilt in order to pick up the changes that were made in Ubuntu Noble. This should solve the problem, and IMHO is a reasonable thing to expect Oracle to do given that Ubuntu Noble is an entirely new release of Ubuntu.

I am going to set this bug's status as Triaged, but will mark it as low priority since it's something affecting third-party software.

Thanks!

[Sascha Lucas (sascha-lucas)]

I totally disagree with "something needs to be rebuilt in order to pick up the changes". The Debian maintainer made clear, that the change in SONAME is temporary for Debian testing and would never make it into the next Debian release.

Only because Ubuntu is a random snapshot of Debian testing, it now has to deal on its own, how to resolve the SONAME change.

[Athos Ribeiro (athos-ribeiro)]

> Only because Ubuntu is a random snapshot of Debian testing [...]

Ubuntu packages are pulled from unstable, not testing.

> I totally disagree with "something needs to be rebuilt in order to pick up the changes".

This is how the package was released in noble. It does make sense to expect third parties to adjust their software in this case. However, I also understand this may be a special case.

> The Debian maintainer made clear, that the change in SONAME is temporary for Debian testing and would never make it into the next Debian release.

Then in this case, it could make sense to wait until

> until this had been agreed with them [upstream].

is resolved before we decide to make any changes to a stable release package. I wonder what is the current status here.

Moreover, there is a simple workaround described in https://forums.oracle.com/ords/apexds/post/instant-client-on-ubuntu-24-04-noble-numbat-7244, which is to create a local symlink with the SO file name that the oracle instant client searches for.

Do you know of any other popular cases where this causes such issue?

Finally, the following discussion may be relevant: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067831

[Romain Geissler (rgeissler-1a)]

Hi,

For me there was a problem which slipped through a release, ok that's unfortunate, but now I would naively expect we try to make it less intrusive to users who have been caught in this. (IMO I am not sure on Debian side it was a good idea to push a soname change + package name change which had always meant to be temporary and reverted before the release, but this is not a discussion for this thread). For me I don't really see how just adding the symlink mentioned at the beginning can cause more harm than the soname and package name caused already, and on the other side I see this fix at least some cases (it would in particular make Oracle instant client work out of the box, provided you install the package libaio1t64 beforehand).

The second part of the potential "compatibility fix" is the problem of package being renamed, and naively I would expect to have some compat package that would install the "new" (which is temporary) name. Indeed I don't see much the value in forcing every third party packager to have a special case in their own dependencies, and depend on libaio1 in Ubuntu <= 22.04 and future Ubuntu >= 26.04 but depend on libaio1t64 in Ubuntu 24.04, and I do see frustration on third part side for this specific case.

(Note: this is my view only, as both a user of ubuntu, and a third party packager for packages internal to my organization, which depend on libaio and did hit this issue).

[Robie Basak (racb)]

@Steve could you comment please?

[Steve Langasek (vorlon)]

On Wed, Jul 10, 2024 at 03:08:42PM -0000, Robie Basak wrote:
> @Steve could you comment please?

According to the Debian maintainer in the changelog:

    - Perform a SONAME bump to avoid stomping on upstream SONAME. Once and if
      the new symbols are accepted by upstream then we can merge that back
      into libaio.so.1 and drop the t64 packages and temporarily provide
      a compat symlink for the t64 SONAME for a smooth transition back. This
      should also be an easier way to revert this transition when there are
      no file conflicts involved, and does not block on upstream support.

There has been no change to this status yet in Debian unstable.

[Robie Basak (racb)]

Sorry Steve, I should have been more specific. Assuming there is no change in Debian's status, do you think it's appropriate for Ubuntu to create a compat symlink in the meantime, and if so, appropriate for SRU to 24.04?

Personally I'm inclined to say that it doesn't make sense if the soname ends up moving forward rather than backwards, and we don't know about that status yet. Because normally for a soname bump we expect third parties to link to the new name, and we do not expect to provide backwards ABI compatibility across releases.

If the soname does actually go back, then perhaps it makes sense as an exception to provide a compat symlink in some form, but I'd prefer not to "kick the can down the road" if it going backwards doesn't actually end up happening.