Fedora Account System
Red Hat Associate
Red Hat Customer
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
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.
(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.
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.
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.
*** Bug 1464368 has been marked as a duplicate of this bug. ***