According to https://bugzilla.redhat.com/show_bug.cgi?id=2180842, dnf with some (maybe default) settings does not support file dependencies on /sbin/ldconfig, and these are generated automatically if you use the recommended %post -p /sbin/ldconfig and such or included explicitly if you use our recommended Requires(post): /sbin/ldconfig etc.
/sbin/ldconfig
%post -p /sbin/ldconfig
Requires(post): /sbin/ldconfig
Not supporting this seems broken to me, but if that's really the case then we probably shouldn't be recommending something that doesn't work. Note that because of the file trigger work done some time ago, this is only required if the package installs linker configuration files so such usage is rare.
I can send a PR but figure I may be misunderstanding what's happening under the hood.
Nobody should be doing %post -p /sbin/ldconfig anymore for anything since https://fedoraproject.org/wiki/Changes/Removing_ldconfig_scriptlets in F28.
Even if they install linker configuration files in /etc/ld.so.conf.d? https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_linker_configuration_files indicates that it is absolutely mandatory.
Yes, if the package has linker configuration, it's necessary to run ldconfig manually ... because the file trigger doesn't run if libraries are installed to non-standard locations. The llvm15 / llvm14 / llvm13 etc. compat packages are examples of this ... and depending on the order of things getting installed, binaries can fail to launch, for example:
https://bugzilla.redhat.com/show_bug.cgi?id=2001328
Well, a workaround for this if dnf5 can't fix it so that file dependencies from primary.xml are read is to add Provides: /sbin/ldconfig to the package that has ldconfig in it.
Provides: /sbin/ldconfig
ldconfig
glibc already does provide /sbin/ldconfig but it does not help in this case.
I think it would be theoretically possible for file triggers on /etc/ld.so.conf.d to at least avoid the initial call to ldconfig but it would still be required for the package to add the triggers for the new library directory and we would still need to decide whether to update the path to ldconfig in those triggers.
/etc/ld.so.conf.d
I would like to revisit this. https://bugzilla.redhat.com/show_bug.cgi?id=2180842 is still open but I guess I just don't understand what the real issue is besides DNF5 unilaterally deciding to just break most file dependencies.
It doesn't really seem to me to be productive to change /sbin/ldconfig to /usr/sbin/ldconfig throughout the guidelines, and there are going to be a whole lot of dependencies on /bin/sh or /bin/bash throughout the distribution so this kind of has to work somehow.
/usr/sbin/ldconfig
/bin/sh
/bin/bash
Though this does point out that if DNF5 is really going to completely break file dependencies outside of /etc, /usr/bin and /usr/sbin, then we're going to have to change https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_directory_dependencies to ban those dependencies outright instead of saying "SHOULD NOT" as we do now.
/etc
/usr/bin
/usr/sbin
Metadata Update from @tibbs: - Issue tagged with: meeting
If /bin//sbin file paths are not resolving, that's a bug that needs to be fixed. They are part of primary.xml and should work.
/bin
/sbin
primary.xml
According to https://bugzilla.redhat.com/show_bug.cgi?id=2180842, only /etc, /usr/bin and /usr/sbin will work. Also, "/sbin symlink is Fedora specific and DNF does not support it." But at some point there was some change in glibc and those /sbin/ldconfig dependencies started to work somehow. The last comment in the bug is asking for the packaging guidelines to be changed to avoid confusion.
Metadata Update from @james: - Issue close_status updated to: nothingtodo - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.