On Fri, 2024-04-05 at 09:22:04 +0200, Raphael Hertzog wrote: > On mer., 27 mars 2024, Guillem Jover wrote: > > A binNMU would fix that, but given that no one has apparently asked > > for that yet, I think instead I'll just add (later today) a compat > > symlink only for the udeb for the old SONAME, because the new SONAME is > > ABI compatible, but done to avoid stomping on the upstream SONAME in > > case they end up merging something else or rejecting the patches, but > > in d-i we do not care about backwards compatibility as long as it is > > ABI compatible, then no binNMU will be needed anymore. > > Would it be problematic to add the same compat symlink in the main > library package?
I think so yes, because if the intention is to reverse the SONAME bump (while adding the t64 symlinks also on the reintroduced libaio1 package), then I'd need to add Replaces in both directions which would then depend on the installation order. :/ > Since the SONAME is changed, the presence of the compat symlink would > not change anything on your decision: new software compiled against the > library would link against the new SONAME, but software compiled against > the old SONAME would continue to work (since ABI is compatible). > > There are (proprietary) software out there that link against it and we > happen to ship some in Kali's non-free (oracle-instantclient-*). > > https://pkg.kali.org/pkg/oracle-instantclient-basic > https://pkg.kali.org/pkg/oracle-instantclient-devel > > It would be nice if we could continue to keep compabitility with binaries > compiled against upstream's SONAME. I'll try to fix the Linux issue so that I can send the patches upstream, although perhaps I could send these right away and leave the 64-bit syscall part for later, so that I can potentially revert this as soon as possible in Debian. Will check during the weekend. Thanks, Guillem
