[RFC] Automatically generate deps for dlopen() deps?

[poettering]

Many of systemd's library dependencies were turned into dlopen() based dependencies in the recent years/months. For classic package managers these are hard to automatically turn into package dependencies, because they are not mentioned in the ELF header.

In this issue over on the systemd project I am proposing to change something about it: systemd/systemd#32234

I was wondering if there's any interest in this from the rpm camp?

The concept is generic, but systemd would be the first providers of this information I guess. You can extract this kind of "weak" dlopen library dependencies via readelf -p .note.uapi.dlopen or an equivalent command from ELF.

Anyway, would love your input on that issue, in case you are interested in this.

[ffesti]

We welcome an automatic way to add these sort of dependencies automatically without packagers needing to care. I don't have a deeper insight or strong opinion whether these ELF entries are the best way of doing that. Having this as part of the (C) code is probably a good idea if upstreams can be bothered to add them.

Rpm has file attributes which run the automatic dependency generators. E.g. https://github.com/rpm-software-management/rpm/blob/master/fileattrs/elf.attr for ELF files. There are various ways to add this to RPM. Having a separate file attribute, extend the one above or even get this integrated into the elfdeps utility: https://github.com/rpm-software-management/rpm/blob/master/tools/elfdeps.c

The later is probably the best solutions as it avoid opening all these ELF files a second time.

[mcatanzaro]

It seems this header is intended to indicate the list of libraries that might possibly be dlopened, which would best correspond to an RPM Suggests dependency. Suggests has limited value because dnf doesn't do anything with it by default. We might need a way for the ELF header to distinguish between which type of dep should be generated: Requires (always needed), Recommends (optional but dnf should install it automatically), or Suggests (optional and dnf should not install it automatically, so not very useful).

Alternatively, we could establish some rules on what types of deps are appropriate to encode in the ELF header. Recommends is probably generally the right choice for most dlopen deps, so we could say RPM will always generate Recommends and you shouldn't add the library to the ELF header at all if Suggests would be more appropriate. But I think that's not how you currently intend to use this functionality, right? You expect it to be a list of what might possibly be dlopened? That would be Suggests, and that is just not very useful IMO.

[poettering]

alternatively, you could just process this in a "linting" context, i.e. at package building simply refuse building if the deps listed in the new ELF note are not listed under either Requires, Suggests, or Recommends (or some ignore list). That way it is guaranteed the packager figures out what to do with each dep, i.e. what to turn this into, and thus a missing dep will result in a build failure rather than a runtime error for the end user. but dunno, this is of course something that RPM toolchain maintainers need to figure out how to do this best, i.e. just automatic dep generation, just linting, or maybe some mixture of both schemes.