Bug 2259260

Summary:	rpm: tools/elfdeps.c should default to filtering based on system search paths when generating provides
Product:	[Fedora] Fedora	Reporter:	Carlos O'Donell <codonell>
Component:	rpm	Assignee:	Packaging Maintenance Team <packaging-team-maint>
Status:	CLOSED UPSTREAM	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	fweimer, igor.raits, jwakely, mdomonko, mjw, packaging-team-maint, pmatilai, praiskup
Target Milestone:	---	Keywords:	RFE
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2024-01-24 09:41:15 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Carlos O'Donell 2024-01-19 19:57:32 UTC

The rpm elfdeps tool is used during rpm building to generate automatic provides for a package. The elfdeps tool generates ELF shared object provides regardless of the path on which the shared object resides.

When a package bundles a shared library in a non-system package-controlled directory, that at some point matches a system-provided version, other packages using the system version may have their dependencies met by the private bundled shared object and fail to run correctly due to missing shared objects.

The most recent example is this:
Bug 2249305 - condor-23.1.0-1.fc40 provides libfmt.so.10()(64bit) from bundled version of libfmt
https://bugzilla.redhat.com/show_bug.cgi?id=2249305

Where condor ends up providing libfmt.so.10 in a package-controlled directory, but this leaks out into the distribution.

As an upstream glibc maintainer, and developer of a dynamic loader, what rpm's elfdeps really wants to do is emulate the DSOs that would be found at runtime, but that is a difficult proposition for the build tool.

I think we can do better here during the generation of automatic provides by only providing shared objects that appear in known directories, and everything else has to be specified by hand. This would avoid accidental inclusion like happened where condor broke the buildroot.

I'm filling this in downstream Fedora right now so we don't forget the issue, and because the list of directories to search might be distribution specific. There may be an upstream component to this fix which likely includes processing an additional argument on the command line. However, we could just as likely limit what we pass to elfdeps in Fedora.


Reproducible: Always

Comment 1 Panu Matilainen 2024-01-24 08:38:02 UTC

It's not exactly the first time this has been brought up.

The problem is that the user of the private copy will still have package internal requires on it, which will then be unmet. Rpm doesn't differentiate between internal and external dependencies basically because it tracks dependencies on file-level as installed files of a package can vary. And such.

I've yet to see any good solutions to this. As it is, packagers are expected to manually filter out bundled dependencies.

Comment 2 Florian Weimer 2024-01-24 08:45:31 UTC

(In reply to Panu Matilainen from comment #1)
> It's not exactly the first time this has been brought up.
> 
> The problem is that the user of the private copy will still have package
> internal requires on it, which will then be unmet. Rpm doesn't differentiate
> between internal and external dependencies basically because it tracks
> dependencies on file-level as installed files of a package can vary. And
> such.

They key difference is that those unsatisfied internal dependencies impact only that one package, and not the whole distribution. With the current approach, it's possible to do something reasonable (package an upstream project in the way recommended by upstream—bundling is now allowed) and break the whole distribution by accident. It's another thing that makes Fedora contributions potentially less approachable.

But I get that this isn't something that has an easy solution.

Comment 3 Panu Matilainen 2024-01-24 09:00:32 UTC

Right, bundling being allowed now is a pretty significant change.

Filtering out doesn't work, but perhaps the internal dependencies could be transformed into something that makes them stand out. Provides is easier, requires are harder since it requires resolving which is something rpm doesn't do during builds.

But, this belongs to https://github.com/rpm-software-management/rpm/discussions/categories/ideas really.

Comment 4 Panu Matilainen 2024-01-24 09:41:15 UTC

I started an upstream discussion on this: https://github.com/rpm-software-management/rpm/discussions/2872

Let's continue this there. For anybody not on GH, discussions are gated to rpm-maint email list too.

Comment 5 Panu Matilainen 2024-01-24 09:42:25 UTC

*** Bug 1464368 has been marked as a duplicate of this bug. ***