If you go for %transfiletriggerin/postun and attempt to only call ldconfig at the end of the transaction, you have to ensure that packages actually include any symlinks which ldconfig would create in order for the libraries to actually be "there" at the end of the transaction

As far as I know this isn't a problem, all packages come with both the realname and soname so all ldconfig is doing is updating the cache file.

I've also heard that replacing ldconfig scriptlets with /bin/true in the installer doesn't break anything.

We discussed this at this weeks meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2016-10-06/fpc.2016-10-06-16.00.txt):

• 654 glibc file triggers (geppetto, 17:00:55)

• LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1380878 (tibbs,
  17:14:14)
• ACTION: Need to convince glibc devs. (geppetto, 17:14:49)

There's been a little action in bugzilla. Basically in order for this to progress (i.e. for the glibc folks to even consider switching to scriptlets) we need to amend the packaging guidelines to require that packages include all of the relevant DSO symlinks instead of expecting ldconfig to create them.

Then work with RPM maintainers is required to get something in place for unpackaged DSO symlinks to fail builds. They won't tolerate the idea that an unpackaged symlink and no immediate post install ldconfig call leads to basically random behavior. I think all that's required is that ldconfig is called in %_os_install_post (probably via a script with some provided way to disable it if necessary). This would just result in an error about unpackaged files if the DSO symlinks aren't packaged.

Then I think once queries for problematic packages in symboldb show nothing, they can activate some triggers and we can start removing the scriptlets from packages.

There's the remaining question about packages which add things to /etc/ld.so.conf.d; for those, ldconfig needs to run immediately after the package is installed instead of at the end of the transaction. The obvious solution there is a separate trigger on that one directory, but for some reason I've proposed that three times and have been ignored.

In any case, this has been a bit frustrating, and I'm out of energy to push this forward. Basically there's a strong resistance to change on the glibc side and the expectation that we demonstrate zero possibility of fallout from this.

We discussed this at this weeks meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2017-08-17/fpc.2017-08-17-16.00.txt):

• x654 glibc file triggers (geppetto, 16:10:23)
• ldconfig -Nr %{buildroot} … seems like it should be the command to
  run. (geppetto, 16:26:28)

To make sure it's noticed by FPC as well, I did post a comment in the bug that basically amounted to:

• This is being made way harder than it actually is
• It seems like glibc folks won't actually implement it unless forced to

For what it's worth, the only difference between Mageia and Fedora in packaging (w.r.t. libraries) is that Mageia mandates all libraries to be split out into their own packages (like openSUSE does). From the point of view of the file triggers, this doesn't really matter.

For handling virtually all cases, this is all that should be necessary:

%filetriggerin -p /sbin/ldconfig -P 2000000 -- /etc/ld.so.conf.d
%filetriggerun -p /sbin/ldconfig -P 2000000 -- /etc/ld.so.conf.d
%transfiletriggerin -p /sbin/ldconfig -P 2000000 -- /lib /usr/lib /lib64 /usr/lib64
%transfiletriggerpostun -p /sbin/ldconfig -P 2000000 -- /lib /usr/lib /lib64 /usr/lib64

Seems this is progressing. From our end, the glibc folks want us to specify what the file triggers should look for a package which installs something into /etc/ld.so.conf.d that tells ldconfig to look at some location which is not under one of (/lib, /usr/lib, /lib64, /usr/lib64). Currently there are no packages in Fedora which do this so I hope it won't be a blocker, but I will open a separate ticket to cover the draft for that bit.

So it seems that a portion of this is now live in rawhide. The two transfiletriggers are there, but the triggers for ld.so.conf.d are not. So, joy and celebration that there has been progress.

So FPC now has work to do:

• Convenience macros exist in rawhide and in the following updates, which would go out quickly if a few of us gave karma:
  • F26: https://bodhi.fedoraproject.org/updates/FEDORA-2018-24006fc98f
  • F27: https://bodhi.fedoraproject.org/updates/FEDORA-2018-10c65d1442
  • EPEL6: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-580a31cb75
  • EPEL7: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-c5ae067f71
• Guideline changes are needed to remove the existing ldconfig bits and instead add mention of the %ldconfig_scriptlets macro (which does the right thing on all releases which need it and does nothing at all otherwise).
• We have no guidelines for ld.so.conf.d at all and we probably should have had them all along. They need to say what you do when you place something there (which is to call ldconfig....) and also what file triggers you should add when you add library paths which are not under the standard paths.

I'll add some draft changes here in this ticket in a bit.

Here's a quick go at what needs to change. This is, unfortunately, a lot of stuff. So for the most part we're removing stuff that packagers need to care about, but paradoxically this actually adds stuff to the guidelines. And the last section about ld.so.conf.d feels kind of tortured.

• Remove all mention of ldconfig from https://fedoraproject.org/wiki/Packaging:Guidelines#Shared_Libraries. Link to the proper section of the Scriptlets guideline instead. The section becomes the following:

Shared Libraries

Whenever possible (and feasible), Fedora packages containing libraries SHOULD build them as shared libraries. See [[Packaging:Scriptlets#Shared_Libraries]] for information about whether scriptlets are required.

• Then the relevant scriptlet section needs significant revision:

Shared Libraries

On Fedora 28 and newer, no scriptlets are required. However, the following scriptlets MAY be used, as they will simply evaluate to nothing on newer Fedora releases.

On Fedora 27 and older, ldconfig MUST be called properly in order to regenerate the dynamic linker's cache. If the package or subpackage has no existing %post or %postun scriptlets, simply include the %ldconfig_scriptlets macro on its own line before the %files list. As with other scriptlets, the -n option is used to apply the scriptlet to a subpackage.

[...]
%install
# Install the program

%ldconfig_scriptlets -n libs

%files -n libs
license GPL
[,,,]

Using the %ldconfig_scriptlets macro will automatically generate a dependency on ldconfig where necessary. And the macro will do nothing at all on F28 or newer, so it can be used without

If the package or subpackage already has existing %post or %postun scriptlet, then use of %ldconfig_scrfiptlets will cause an error. You can use %ldconfig_post or %ldconfig_postun individually to generate a scriptlet which doesn't already conflict.

Within an existing %post or %postun scriptlet, use %{?ldconfig} on its own line to call ldconfig on those releases which need it. This will do nothing when not needed. When calling ldconfig in this way, you MUST also have the proper dependency on /sbin/ldconfig: Requires(post): /sbin/ldconfig and/or Requires(postun): /sbin/ldconfig as appropriate. (This will generate an unnecessary dependency on releases which do not strictly need it, but this does no harm.

• An additional section in the scriptlets page is needed for ld.so.conf.d:

Linker Configuration Files

Packages which place linker configuration files in /etc/ld.so.config.d MUST call ldconfig in %post and %postun (on all Fedora releases) even if they install no actual libraries. They MUST NOT use the %ldconfig, %ldconfig_post, %ldconfig_postun or %ldconfig_scriptlets macros to do this, since these macros do not have any effect on Fedora 28 and newer. Instead simply call /sbin/ldconfig directly in both %post and %postun as well as adding the necessary dependencies when necessary:

%post -p /sbin/ldconfig
%postun -p /sbin/ldconfig

or, as part of existing %post or %postun scriptlets:

Requires(post): /sbin/ldconfig
Requires(postun): /sbin/ldconfig
[...]
%post
[...]
/sbin/ldconfig
[...]
%postun
[...]
/sbin/ldconfig
[...]

In addition, in Fedora 28 or newer the following applies: If the configuration file added to /etc/ld.so.conf.d specifies a directory into which other other packages may install files, and that directory is not located in the directory hierarchy beneath one of /lib, /usr/lib</code, <code>/lib64 or /usr/lib64, then the package adding the configuration file MUST also include the following file triggers which cause ldconfig to be run automatically when necessary:

%transfiletriggerin -P 2000000 -- DIRECTORIES
/sbin/ldconfig

%transfiletriggerpostun -P 2000000 -- DIRECTORIES
/sbin/ldconfig

Replace DIRECTORIES with the space-separated list of directories which the package adds to to the library search path via the configuration files in /etc/ld.so.conf.d.

@tibbs, remove -n in -n libs, because it means package named lib, not the subpackage. So it should be %ldconfig_scriptlets libs

Requires(post): /sbin/ldconfig

hmm, shouldn't we propose something like %{?ldconfig:Requires(post): %ldconfig}?

/etc/ld.so.config.d → /etc/ld.so.conf.d..

%transfiletriggerin -p /sbin/ldconfig -P 2000000 -- DIRECTORIES

Turned out this didn't work correctly because RPM did pass some extra stuff... So in glibc we switched to

%transfiletriggerin -p <lua> -P 2000000 -- DIRECTORIES
os.execute("/sbin/ldconfig")

I was avoiding proposing %{?ldconfig:Requires(post): %ldconfig} because that's too much line noise to avoid one dependency which has zero effect. We could easily do %ldconfig_requires, I guess, but even then it's so terribly minor. I did mention that in the proposal but maybe %ldconfig_requires a smart way to avoid the questions (and it's a line shorter than being explicit.

I edited the file triggers bit. However, is it really necessary for packages other than glibc to use lua? There's no point in making it more complicated than necessary, so wouldn't this work?

%transfiletriggerin -P 2000000 -- DIRECTORIES
/sbin/ldconfig

%transfiletriggerin -P 2000000 -- DIRECTORIES
/sbin/ldconfig

This should work.

We discussed this at this weeks meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2018-02-01/fpc.2018-02-01-17.00.txt):

• x654 glibc file triggers (geppetto, 17:07:34)
• ACTION: Policy changes due to glibc file triggers from the ticket
  (+1:5, 0:0, -1:0) (geppetto, 17:15:03)

Well, I wrote this up. And then I realized that all of the macros are only in rawhide. But the updates have three karma apiece, so it shouldn't be too long. Rather than reverting, I'll just hold off on making an announcement for a bit.

Note that there is build override for all of them.

I actually made the announcement a while back; not sure why I didn't close this.