Hello, On Sun, Feb 26, 2023 at 10:03:58AM -0500, Emanuel Castelo wrote:

Is the issue Fedora specific? Has the issue been seen in OpenSuse/Suse?

It's specific to the rpm dependency generator. So long as it is used in opneSUSE/SUSE and not completely replaced by external one it affects how dependencies are generated. This breaks compat libraries. The ones that were mentioned are libsdl-compat and PipeWire-JACK, other potential candidates are OpenGL libraries although those may be using hand-crafted dependencies anyway. The other problem is that this requires rebuilding the world because the dependencies are not backwards compatible. With Leap inheriting packages built on ancient SLE versions we cannot enable this. This would then only work for Factory and ALP that can still be rebuilt. For backward compatibility it would be necessary to figure out if the package providing the library already has the new style dependey, and generete the new style dependency only when it does. FWIW Debian actually tracks which symbols are available in which library version and generates dependencies based on the symbols used and the library version in which they appeared. That means that binary built against newest library version that only uses ancient functions still depends on acient version of the library. This also does not work well with compatibility libraries. Thanks Michal

Sent from my iPad

Begin forwarded message:

...

From: Gordon Messmer Date: February 25, 2023 at 23:11:12 EST To: factory@lists.opensuse.org Subject: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

Following a recent thread on the Fedora devel@ mailing list discussing a reproducible failure caused by mismatched library interfaces, I proposed a change to the RPM ELF dependency generator. After discussion in the PR, I've provided an implementation suggested by keszybz@ which would use the "full name" versions collected from library filenames to provide versioned library requirements. Before merging that feature, RPM's maintainers are interested in feedback from a wider audience.

If the feature linked below is merged into rpm, would SUSE be interested in using it? Do you have any suggestions to improve the feature, before it's merged?

Discussion of the rpm problem: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...

Discussion of the proposed feature: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...

Implementation of the proposed feature: https://github.com/rpm-software-management/rpm/pull/2372

On Sun, Feb 26, 2023 at 11:36:09AM -0800, Gordon Messmer wrote:

On 2023-02-26 09:46, Michal Suchánek wrote:

...

The other problem is that this requires rebuilding the world because the dependencies are not backwards compatible. With Leap inheriting packages built on ancient SLE versions we cannot enable this.

This would then only work for Factory and ALP that can still be rebuilt. For backward compatibility it would be necessary to figure out if the package providing the library already has the new style dependey, and generete the new style dependency only when it does.

I can discuss the possibility of querying the rpm DB from the generator (or possibly storing some indication of a versioned provide: in the filesystem) with the RPM developers.  Would the change be more interesting if that feature were included?

It would be more feasible to include as an update. If tehre is interest from release managers and rpm tool maintainers is a separate question.

...

FWIW Debian actually tracks which symbols are available in which library version and generates dependencies based on the symbols used and the library version in which they appeared.

I've looked briefly at dpkg dependencies, and didn't see that. How would I view that information in a dpkg file?  How does the dpkg dependency generator know what version the symbols appeared in?

It's stored in the package sources, and checked, and updated during package build: https://salsa.debian.org/systemd-team/systemd/-/blob/debian/master/debian/li... https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#the-symbols-syst... Thanks Michal

On Sun, Feb 26, Jan Engelhardt wrote:

On Sunday 2023-02-26 16:03, Emanuel Castelo wrote:

...

Is the issue Fedora specific? Has the issue been seen in OpenSuse/Suse?

No. Yes, regularly. (e.g. https://bugzilla.suse.com/show_bug.cgi?id=903974 )

This sounds like it would be more usefull to teach this projects (correct) symbol versioning for libraries... Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman (HRB 36809, AG Nürnberg)

On 2023-02-26 10:05, Thorsten Kukuk wrote:

This sounds like it would be more usefull to teach this projects (correct) symbol versioning for libraries...

Yes, versioned symbols are preferred, and I make that point in the documentation for the feature I'm proposing.  But waiting for library maintainers to version their symbols has not resolved the problem yet, and I think we should be taking steps to address the problem while we continue waiting on them.

On 2023-02-26 10:12, Stefan Brüns wrote:

The correct way to fix this is proper symbol versioning. Unfortunately, too few projects make use of it.

Yes, I agree.  Versioned symbols are preferred, and the documentation for this proposal states that.

But enabling this in general would be a major step backwards for all projects which *do* use symbol versioning, and all dependent packages.

This feature doesn't change dependency generation for libraries that use versioned symbols, because those are already well handled.  It only affects libraries that don't use versioned symbols.

This also would not work in general, as some projects may add symbols without changing the "fullname".

You're right, that this wouldn't be a 100% reliable solution. About 10% of all libraries in Fedora's repos appear to use version "0.0.0" in their full name.  But a 90% solution is still far better than a 0% solution. I've also proposed a change to rpminspect that would detect an ABI change without a full name version change in order to detect exactly that condition and prevent it from silently rolling out. (I don't know if SUSE is using rpminspect in their build pipeline.)

I think this is only useful as an opt-in. In case a library is known to miss proper symbol versioning, the package maintainer(s) can select this behavior.

Does the fact that it doesn't affect libraries with versioned symbols change your opinion at all?

On Monday 2023-02-27 09:33, Richard Biener wrote:

...

If the feature linked below is merged into rpm, would SUSE be interested in using it?  Do you have any suggestions to improve the feature, before it's merged?

One could even hope that upstream libtool could raise awareness by dumping a file with the actual symbols exported [...] libtool could even generate a version script based on the old version of the file and add new symbols always to the latest version.

Sounds commendable, but if we fix libtool, then the meson users get it wrong next. Then the cmake users. I'm dreading to think about what to do about all those plain Makefile writers. Interjecting at the distro level is a must-have.