DevHeads.net

RPM packaging and ldconfig handling

The glibc team has received a request to change the way ldconfig
invocations during package installations and deinstallations are handled.

<a href="https://src.fedoraproject.org/rpms/glibc/pull-request/5" title="https://src.fedoraproject.org/rpms/glibc/pull-request/5">https://src.fedoraproject.org/rpms/glibc/pull-request/5</a>
<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1380878" title="https://bugzilla.redhat.com/show_bug.cgi?id=1380878">https://bugzilla.redhat.com/show_bug.cgi?id=1380878</a>

Some background: ldconfig serves several functions. Key aspects are:

1. Speed up programing loading.

2. Enable the dynamic linker to load libraries by their soname.

3. Enable the dynamic linker to load libraries in directories listed in
/etc/ld.so.conf and /etc/ld.so.conf.d.

The first point is a performance issue and does not matter in this
context. Item 2 and 3, however, can cause program invocation to fail if
ldconfig is not run and certain changes are made to the system.

The Packaging Guidelines currently require that packages must call
ldconfig if they install or install shared objects:

<a href="https://fedoraproject.org/wiki/Packaging:Guidelines#Shared_Libraries" title="https://fedoraproject.org/wiki/Packaging:Guidelines#Shared_Libraries">https://fedoraproject.org/wiki/Packaging:Guidelines#Shared_Libraries</a>

I assume that the goal of the proposal is to reduce both maintainer
overhead and speed up package installation, by removing the ldconfig
invocations from individual packages. This is indeed worthwhile.

However, we need to make sure that when subsequent RPM scriptlets are
executed after the installation or update of a shared object, they see a
system which is usable, so that they can run all the programs listed in
the RPM dependencies.

The latest proposal has this change for the glibc spec file, in order to
deal with the issue of item 2:

# File triggers for when libraries are added or removed in standard paths
%transfiletriggerin -p /sbin/ldconfig -P 2000000 -- /lib /usr/lib /lib64
/usr/lib64

%transfiletriggerpostun -p /sbin/ldconfig -P 2000000 -- /lib /usr/lib
/lib64 /usr/lib64

But this will run at the end of the transaction, which is too late for
other scriptlets (which, for %post, run immediately after unpacking an
RPM package).

It would not be a good idea to turn the triggers into %filetriggerin and
%filetriggerun, in my opinion. They would run after the installation of
the package, but since the paths specify entire directory trees, the
trigger would fire for the installation of many noarch packages to due
to the /usr/lib path (e.g., Python packages are installed into
/usr/lib/python*/site-packages/bugzilla).

We can still skip running ldconfig if we can otherwise make sure that
the symbolic links for the DSO sonames are available, so that we simply
have a minor performance issue. ldconfig would still have to be run by
%transfiletriggerin and %transfiletriggerpostun to optimize the system,
but the precise point at time when this has to happen does not matter,
except that it should happen after RPM removed all files to be deleted
during the RPM transaction (which generally happens toward the end,
during the cleanup phase, and not immediately after the installation of
a different package version). As far as I can tell, even with a
successful cache lookup, the dynamic loader still uses the soname
symbolic link to open the DSO file, so renaming the implementation name
(say, for libc-2.25.so to libc-2.26.so) would not lead to temporary
breakage.

We would however make sure that at RPM packaging time, the symbolic
links are created automatically (otherwise the goal of reducing
maintainer overhead would not be met).

For item 3 (shared objects in non-default directories), I think the
proposed change for the glibc:

%filetriggerin -p /sbin/ldconfig -P 2000000 -- /etc/ld.so.conf.d
%filetriggerun -p /sbin/ldconfig -P 2000000 -- /etc/ld.so.conf.d

should work in most cases, except when the configuration file is in a
separate -common package which might not be (un)installed before or
after the package which contains the DSO file (so that the automatic
ldconfig invocation does not happen at the right point in time).
However, these packages are rare, so perhaps it would be preferable to
keep the explicit ldconfig invocations in the packages for explicitness
(and generally discourage the use of non-default search paths).

For all these triggers, we need to carefully consider the -P priority
value and document it in the Packaging Guidelines.

In any case, I don't think we can just make a change to the glibc
package, an update of the Packaging Guidelines is needed as well, if
only for the “must call ldconfig” part.

Thanks,
Florian

Comments

Re: RPM packaging and ldconfig handling

By Florian Weimer at 01/29/2018 - 13:18

Igor committed a change to glibc so that from Fedora 28 going forward,
glibc will run ldconfig after the transaction if any of the library
directory trees was modified.

This means that libraries which package the lib*.so.* symbolic links
will no longer have to run ldconfig in %postin/%postun, and we can
automate the creation of those symbolic links with a buildroot policy
hook, see:

<https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/12>

Packages which edit ld.so search paths will still have to run ldconfig
in %postin/%postun, as before.

Thanks,
Florian

Re: RPM packaging and ldconfig handling

By =?ISO-8859-1?Q?... at 01/30/2018 - 04:02

~~~

+ /usr/lib/rpm/redhat/brp-ldconfig
/sbin/ldconfig: Warning: ignoring configuration file that cannot be
opened: /etc/ld.so.conf: No such file or directory

~~~

What is this ^^? Should I be worried about it?

V.

Dne 29.1.2018 v 18:18 Florian Weimer napsal(a):

Re: RPM packaging and ldconfig handling

By Igor Gnatenko at 01/30/2018 - 04:57

Hash: SHA256

On Tue, 2018-01-30 at 09:02 +0100, Vít Ondruch wrote:
brp-ldconfig simply calls `/sbin/ldconfig -N -r "$RPM_BUILD_ROOT"` and there is
no /etc/ld.so.conf under $RPM_BUILD_ROOT when you build... In theory we could
supply one (empty), but I would ask Florian what would be the best to do.

Re: RPM packaging and ldconfig handling

By Kamil Dudka at 01/31/2018 - 08:54

On Tuesday, January 30, 2018 9:57:39 AM CET Igor Gnatenko wrote:
This change broke the build of libcurl{-minimal} because ldconfig now operates
on an intermediate layout of the installed shared libraries, which is needed
by the RemovePathPostfixes feature of RPM, instead of the final layout that is
actually packaged as libcurl and libcurl-minimal.

At the end of %install, the build root contains this:

+ ls -l /builddir/build/BUILDROOT/curl-7.58.0-2.fc28.s390x/usr/lib64
total 8324
lrwxrwxrwx. 1 mockbuild mockbuild 16 Jan 31 12:46 libcurl.so -> libcurl.so.4.5.0
lrwxrwxrwx. 1 mockbuild mockbuild 16 Jan 31 12:46 libcurl.so.4 -> libcurl.so.4.5.0
-rwxr-xr-x. 1 mockbuild mockbuild 4398816 Jan 31 12:46 libcurl.so.4.5.0
-rwxr-xr-x. 1 mockbuild mockbuild 4120952 Jan 31 12:46 libcurl.so.4.5.0.minimal
lrwxrwxrwx. 1 mockbuild mockbuild 16 Jan 31 12:46 libcurl.so.4.minimal -> libcurl.so.4.5.0
drwxr-xr-x. 2 mockbuild mockbuild 24 Jan 31 12:46 pkgconfig

But at the beginning of %check, the build root contains this:

+ ls -l /builddir/build/BUILDROOT/curl-7.58.0-2.fc28.s390x/usr/lib64
total 1172
lrwxrwxrwx. 1 mockbuild mockbuild 16 Jan 31 12:46 libcurl.so -> libcurl.so.4.5.0
lrwxrwxrwx. 1 mockbuild mockbuild 24 Jan 31 12:46 libcurl.so.4 -> libcurl.so.4.5.0.minimal
-rwxr-xr-x. 1 mockbuild mockbuild 614896 Jan 31 12:46 libcurl.so.4.5.0
-rwxr-xr-x. 1 mockbuild mockbuild 577760 Jan 31 12:46 libcurl.so.4.5.0.minimal
lrwxrwxrwx. 1 mockbuild mockbuild 16 Jan 31 12:46 libcurl.so.4.minimal -> libcurl.so.4.5.0
drwxr-xr-x. 2 mockbuild mockbuild 24 Jan 31 12:46 pkgconfig

See that libcurl.so.4 now points to libcurl.so.4.5.0.minimal by mistake.

What is the recommended way to make libcurl{-minimal} build properly again?

Kamil

Re: RPM packaging and ldconfig handling

By Igor Gnatenko at 01/31/2018 - 09:03

Hash: SHA256

On Wed, 2018-01-31 at 13:54 +0100, Kamil Dudka wrote:
Just `%undefine __brp_ldconfig`. And you can safely remove / replace with macro
calls to ldconfig because you are packaging DSO symlinks and it will continue
working fine..

I will think how we can make support for RemovePathPostfixes.

Re: RPM packaging and ldconfig handling

By Richard Shaw at 01/31/2018 - 09:14

I re-skimmed the whole thread so I apologize if I missed it, but I have a
couple of questions:

1. The packaging guidelines still require the explicit use of calling
ldconfig, so even if it's not technically required, it would be against the
guidelines to remove them, correct?

2. Is the plan to update for all supported Fedora releases and not just
Rawhide? Otherwise we're back in conditional hell which I thought we were
trying to move away from. (Again, the suggested workflow in the wiki for
managing branches is to merge across them).

Thanks,
Richard

Re: RPM packaging and ldconfig handling

By King InuYasha at 01/31/2018 - 09:40

On Wed, Jan 31, 2018 at 8:14 AM, Richard Shaw < ... at gmail dot com> wrote:
New guidelines are being drafted:
<a href="https://pagure.io/packaging-committee/issue/654" title="https://pagure.io/packaging-committee/issue/654">https://pagure.io/packaging-committee/issue/654</a>

We could technically push them to all supported Fedora releases, but
that would force a requirement to have a specific minimum version of
glibc per distribution release, and that's just too much. It's easier
to just let it fade out of existence.

In addition, the usage of ldconfig macros being made should make this
a non-issue.

Re: RPM packaging and ldconfig handling

By Igor Gnatenko at 01/31/2018 - 09:38

Hash: SHA256

On Wed, 2018-01-31 at 07:14 -0600, Richard Shaw wrote:
tibbs is working on updating guidelines[0].

If you use macro, then you should not care at all, it will evaluate to ldconfig
calls on old releases and to noop on F28+. This is mentioned on Change Page.

[0] <a href="https://pagure.io/packaging-committee/issue/654" title="https://pagure.io/packaging-committee/issue/654">https://pagure.io/packaging-committee/issue/654</a>

Re: RPM packaging and ldconfig handling

By Richard Shaw at 01/31/2018 - 09:41

On Wed, Jan 31, 2018 at 7:38 AM, Igor Gnatenko <

Thanks for clearing that up for me!

Richard

Re: RPM packaging and ldconfig handling

By Florian Weimer at 01/31/2018 - 09:00

On 01/31/2018 01:54 PM, Kamil Dudka wrote:
I think in this situation, you need to disable this feature using:

%undefine __brp_ldconfig

Depending on whether you can include the appropriate symbolic links in
the packages themselves, you can or cannot remove the explicit ldconfig
calls.

I don't think it's feasible or even desirable to teach ldconfig about
the RemovePathPostfixes RPM feature.

Thanks,
Florian

Re: RPM packaging and ldconfig handling

By Kamil Dudka at 01/31/2018 - 09:53

On Wednesday, January 31, 2018 2:00:08 PM CET Florian Weimer wrote:
Thank both of you for the suggestion! It has indeed resolved the problem.

Those symlinks are created by libtool, so I believe they are appropriate.

%undefine __brp_ldconfig removes the build-time ldconfig calls as I understand
it. Are you saying that I can remove the following install-time ldconfig
calls, too?

%post -n libcurl -p /sbin/ldconfig

%postun -n libcurl -p /sbin/ldconfig

%post -n libcurl-minimal -p /sbin/ldconfig

%postun -n libcurl-minimal -p /sbin/ldconfig

Re: RPM packaging and ldconfig handling

By Igor Gnatenko at 01/31/2018 - 09:55

Hash: SHA256

On Wed, 2018-01-31 at 14:53 +0100, Kamil Dudka wrote:
If you don't simply merge master branch to others, then yes. Otherwise, you
should consider using macro we've created.

%ldconfig_scriptlets -n libcurl
%ldconfig_scriptlets -n libcurl-minimal

Re: RPM packaging and ldconfig handling

By Igor Gnatenko at 01/31/2018 - 09:06

Hash: SHA256

On Wed, 2018-01-31 at 14:00 +0100, Florian Weimer wrote:
Well, we could expose `removePostfixes` as environment variable when brps are
executed, so we could do some workarounds like processing all those libraries
separately followed by renaming soname back.

Shouldn't be hard to do.. I will try to prepare patch later this week.

Re: RPM packaging and ldconfig handling

By Florian Weimer at 01/30/2018 - 05:01

On 01/30/2018 09:57 AM, Igor Gnatenko wrote:
But why does it print /etc/ld.so.conf, and not the path in the
buildroot? That concerns me.

Thanks,
Florian

Re: RPM packaging and ldconfig handling

By =?ISO-8859-1?Q?... at 01/30/2018 - 08:01

Dne 30.1.2018 v 10:01 Florian Weimer napsal(a):
I would be concerned even if it issued warning about /etc/ld.so.conf in
buildroot ...

Vít

Re: RPM packaging and ldconfig handling

By Florian Weimer at 01/30/2018 - 08:06

On 01/30/2018 01:01 PM, Vít Ondruch wrote:
Sure, it would be nice to avoid the warning, and I will work on
something for glibc in rawhide to support this. But I would also like
to understand if ldconfig is actually using the wrong path.

Thanks,
Florian

Re: RPM packaging and ldconfig handling

By Tom Hughes at 01/30/2018 - 08:17

On 30/01/18 12:06, Florian Weimer wrote:
So you're expecting to see $RPM_BUILD_ROOT/etc/ld.so.conf as the
reported path right?

That doesn't seem to be how the -r option to ldconfig works though
because it chroots so as far as it's concerned the relative path is
the path it is accessing:

% sudo strace ldconfig -N -r /tmp
...
chroot("/tmp") = 0
chdir("/") = 0
openat(AT_FDCWD, "/etc/ld.so.conf", O_RDONLY) = -1 ENOENT (No such file
or directory)
...
ldconfig: Warning: ignoring configuration file that cannot be opened:
/etc/ld.so.conf: No such file or directory

Tom

Re: RPM packaging and ldconfig handling

By Florian Weimer at 01/30/2018 - 04:15

On 01/30/2018 09:02 AM, Vít Ondruch wrote:
Context? ldconfig definitely shouldn't print /etc/ld.so.conf.

Thanks,
Florian

Re: RPM packaging and ldconfig handling

By =?ISO-8859-1?Q?... at 01/30/2018 - 04:22

Dne 30.1.2018 v 09:15 Florian Weimer napsal(a):
Local build of Ruby:

~~~
diff --git a/ruby.spec b/ruby.spec
index 6eff5d9..e7b5114 100644
--- a/ruby.spec
+++ b/ruby.spec
@@ -21,7 +21,7 @@
 %endif
 
 
-%global release 87
+%global release 88
 %{!?release_string:%global release_string
%{?development_release:0.}%{release}%{?development_release:.%{development_release}}%{?dist}}
 
 # The RubyGems library has to stay out of Ruby directory three, since the
@@ -742,10 +742,6 @@ sed -i '/def test_mdns_each_address$/,/^  end$/
s/^/#/' test/resolv/test_mdns.rb
 
 make check TESTS="-v $DISABLE_TESTS"
 
-%post libs -p /sbin/ldconfig

Vít

Re: RPM packaging and ldconfig handling

By =?UTF-8?Q?Tomas... at 01/29/2018 - 14:49

As now with file trigger changes are committed and new glibc packages will
be in rawhide repo it should be mass change removing all ldconfig execution
from **ALL** Fedora specs.

[tkloczko@domek SPECS.fedora]$ grep -e '^%post.*/sbin/ldconfig' * | awk
-F\. '{print $1}' | uniq | wc -l
3257
[tkloczko@domek SPECS.fedora]$ grep -e ' */sbin/ldconfig' * | awk -F\.
'{print $1}' | uniq | wc -l
3432

And as well:

[tkloczko@domek SPECS.fedora]$ grep -e '^Requires(post):.*/sbin/ldconfig' *
|wc -l
125
[tkloczko@domek SPECS.fedora]$ grep -e '^Requires(postun):.*/sbin/ldconfig'
* |wc -l
114

This needs to be removed as well. If not it will be like with for example
in hicolor-icon-theme.spec after remove %post/%postun/%postrans
with gtk-update-icon-cache execution still is possible to find in this spec:

Requires(post): coreutils
Requires(postun): coreutils

If all those changes will be not it will be like with other such changes
which never have been finished:

[tkloczko@domek SPECS.fedora]$ grep '^%clean' * | wc -l
3007
[tkloczko@domek SPECS.fedora]$ grep '^BuildRoot:' * | wc -l
2746
[tkloczko@domek SPECS.fedora]$ grep '^Group:' * | wc -l
18065

To be hones I would be personally [1] way happier if Igor will finish first
finish remove hicolor icons theme cache update before jumping on ldconfig.

Just please Igor (or anyone else who will be helping him) do this properly
finishing whole set of necessary changes within as short as it is only
possible time.

Next point which someone needs to take care is update rpmlint to generate
warning that use ldconfig in %post/%postun is no longer needed.

==== And yet another thing connected with above.

I've been many times proposing to use in specs single package/file name
name in each Reqiure or BuildRequires.
I know that many packages do not like this because they are already using
other style.
However it is not about what me or someone else may or may not prefer.
Using single package per Reqiure or BuildRequires is not a matter of
personal preferences because if all those Reqiure/BuildRequires will be
with single package or file path all mass changes will be *way easier to do* by
simple "sed -ie 'd,^Requires(post):.*/sbin/ldconfig,' *spec"

[tkloczko@domek SPECS.fedora]$ grep -e '^Requires(post):.*/sbin/ldconfig' *
acl.spec:Requires(post): /sbin/ldconfig
alsa-lib.spec:Requires(post): /sbin/ldconfig, coreutils
blitz.spec:Requires(post): /sbin/install-info /sbin/ldconfig
cfitsio.spec:Requires(post): /sbin/ldconfig
cinnamon-session.spec:Requires(post): /sbin/ldconfig
Coin2.spec:Requires(post): /sbin/ldconfig
Coin3.spec:Requires(post): /sbin/ldconfig
concordance.spec:Requires(post): /sbin/ldconfig
cyrus-imapd.spec:Requires(post): /sbin/ldconfig
dapl.spec:Requires(post): /sbin/ldconfig
ddccontrol.spec:Requires(post): /sbin/ldconfig
drumstick0.spec:Requires(post): /sbin/ldconfig
drumstick.spec:Requires(post): /sbin/ldconfig
eb.spec:Requires(post): /sbin/ldconfig
eventlog.spec:Requires(post): /sbin/ldconfig
festival.spec:Requires(post): /sbin/ldconfig
festival.spec:Requires(post): /sbin/ldconfig
firebird.spec:Requires(post): /sbin/ldconfig
firebird.spec:Requires(post): /sbin/ldconfig
freehdl.spec:Requires(post): /sbin/install-info /sbin/ldconfig
fwknop.spec:Requires(post): /sbin/ldconfig
gauche.spec:Requires(post): /sbin/install-info, /sbin/ldconfig
gconfmm26.spec:Requires(post): /sbin/ldconfig
geda-gaf.spec:Requires(post): /sbin/ldconfig
gerbv.spec:Requires(post): /sbin/ldconfig
getdata.spec:Requires(post): /sbin/ldconfig
gnucash.spec:Requires(post): /sbin/ldconfig
gnumeric.spec:Requires(post): /sbin/ldconfig
gr-air-modes.spec:Requires(post): /sbin/ldconfig
graphviz.spec:Requires(post): /sbin/ldconfig
graphviz.spec:Requires(post): %{_bindir}/dot /sbin/ldconfig
gr-fcdproplus.spec:Requires(post): /sbin/ldconfig
gr-iqbal.spec:Requires(post): /sbin/ldconfig
groonga.spec:Requires(post): /sbin/ldconfig
gr-osmosdr.spec:Requires(post): /sbin/ldconfig
gtkglextmm.spec:Requires(post): /sbin/ldconfig
gtkglext.spec:Requires(post): /sbin/ldconfig
gwenhywfar.spec:Requires(post): /sbin/ldconfig
hylafax+.spec:Requires(post): /sbin/ldconfig
infiniband-diags.spec:Requires(post): /sbin/ldconfig
infinipath-psm.spec:Requires(post): /sbin/ldconfig
infinipath-psm.spec:Requires(post): /sbin/ldconfig
k3d.spec:Requires(post): /sbin/ldconfig
kdebase3.spec:Requires(post): /sbin/ldconfig
kdelibs3.spec:Requires(post): /sbin/ldconfig
kdelibs.spec:Requires(post): /sbin/ldconfig
kita.spec:Requires(post): /sbin/ldconfig
kst.spec:Requires(post): /sbin/ldconfig
kvirc.spec:Requires(post): /sbin/ldconfig
ledger.spec:Requires(post): /sbin/ldconfig
libannodex.spec:Requires(post): /sbin/ldconfig
libapreq2.spec:Requires(post): /sbin/ldconfig
libcdio.spec:Requires(post): /sbin/ldconfig
libfm.spec:Requires(post): /sbin/ldconfig
libglademm.spec:Requires(post): /sbin/ldconfig
libgle.spec:Requires(post): /sbin/ldconfig
libgnomecanvasmm.spec:Requires(post): /sbin/ldconfig
libhangul.spec:Requires(post): /sbin/ldconfig
libibcommon.spec:Requires(post): /sbin/ldconfig
libidn2.spec:Requires(post): /sbin/install-info, /sbin/ldconfig
libidn.spec:Requires(post): /sbin/install-info /sbin/ldconfig
libitl.spec:Requires(post): /sbin/ldconfig
liblogging.spec:Requires(post): /sbin/ldconfig
liborigin.spec:Requires(post): /sbin/ldconfig
libosmocore.spec:Requires(post): /sbin/ldconfig
libosmo-dsp.spec:Requires(post): /sbin/ldconfig
librelp.spec:Requires(post): /sbin/ldconfig
libsexymm.spec:Requires(post): /sbin/ldconfig
libstroke.spec:Requires(post): /sbin/ldconfig
libstroke.spec:Requires(post): /sbin/ldconfig
libtool.spec:Requires(post): /sbin/ldconfig
libutempter.spec:Requires(post): /sbin/ldconfig
libvma.spec:Requires(post): /sbin/ldconfig
loki-lib.spec:Requires(post): /sbin/ldconfig
miredo.spec:Requires(post): /sbin/ldconfig
mISDN.spec:Requires(post): /sbin/ldconfig
mpfr.spec:Requires(post): /sbin/ldconfig
nss-pam-ldapd.spec:Requires(post): /sbin/ldconfig, chkconfig, grep, sed
oath-toolkit.spec:Requires(post): /sbin/ldconfig
oath-toolkit.spec:Requires(post): /sbin/ldconfig
openscap.spec:Requires(post): /sbin/ldconfig
pam.spec:Requires(post): coreutils, /sbin/ldconfig
parted.spec:Requires(post): /sbin/ldconfig
pilot-link.spec:Requires(post): /sbin/ldconfig
plotutils.spec:Requires(post): /sbin/ldconfig
plplot.spec:Requires(post): /sbin/ldconfig
polkit.spec:Requires(post): /sbin/ldconfig, systemd
procps-ng.spec:Requires(post): /sbin/ldconfig
qmmp.spec:Requires(post): /sbin/ldconfig
q.spec:Requires(post): /sbin/ldconfig /sbin/install-info
rapidsvn.spec:Requires(post): /sbin/ldconfig
recode.spec:Requires(post): /sbin/ldconfig
recutils.spec:Requires(post): /sbin/ldconfig
richacl.spec:Requires(post): /sbin/ldconfig
rtl-sdr.spec:Requires(post): /sbin/ldconfig
sblim-cmpi-fsvol.spec:Requires(post): /sbin/ldconfig
sblim-cmpi-nfsv3.spec:Requires(post): /sbin/ldconfig
sblim-cmpi-nfsv4.spec:Requires(post): /sbin/ldconfig
sblim-cmpi-syslog.spec:Requires(post): /sbin/ldconfig
sblim-smis-hba.spec:Requires(post): /sbin/ldconfig
sim.spec:Requires(post): /sbin/ldconfig
SIMVoleon.spec:Requires(post): /sbin/ldconfig
slimdata.spec:Requires(post): /sbin/ldconfig
SoQt.spec:Requires(post): /sbin/ldconfig
sssd.spec:Requires(post): /sbin/ldconfig
sssd.spec:Requires(post): /sbin/ldconfig
sssd.spec:Requires(post): /sbin/ldconfig
sssd.spec:Requires(post): /sbin/ldconfig
sssd.spec:Requires(post): /sbin/ldconfig
sssd.spec:Requires(post): /sbin/ldconfig
sssd.spec:Requires(post): /sbin/ldconfig
stellarium.spec:Requires(post): /sbin/ldconfig
subtitleeditor.spec:Requires(post): /sbin/ldconfig
tcpcrypt.spec:Requires(post): /sbin/ldconfig
tk.spec:Requires(post): /sbin/ldconfig
tn5250.spec:Requires(post): /sbin/ldconfig
tog-pegasus.spec:Requires(post): /sbin/ldconfig
tog-pegasus.spec:Requires(post): /sbin/ldconfig
uim.spec:Requires(post): %{_sbindir}/update-alternatives /sbin/ldconfig
unbound.spec:Requires(post): /sbin/ldconfig
unuran.spec:Requires(post): /sbin/ldconfig, /sbin/install-info
usbguard.spec:Requires(post): /sbin/ldconfig
wine.spec:Requires(post): /sbin/ldconfig
xalan-c.spec:Requires(post): /sbin/ldconfig
xen.spec:Requires(post): /sbin/ldconfig

[1] [tkloczko@domek SPECS.fedora]$ grep 'gtk-update-icon-cache' * | grep
hicolor | awk -F\. '{print $1}' | uniq | wc -l
304

Still about 2/3 of all above specs are waiting on finish
remove gtk-update-icon-cache execution in %post/%postun/%postrans.
I would be personally happier because I've requested to remove those
updates and Igor have been removing all those executions.
More than 3 weeks after this change started still is not finished.

kloczek

Re: RPM packaging and ldconfig handling

By Igor Gnatenko at 01/29/2018 - 15:06

Hash: SHA256

On Mon, 2018-01-29 at 18:49 +0000, Tomasz Kłoczko wrote:
While I agree that this is needed, why do you point on this here? I mean it's
obvious to everyone that this should be done. No need to point on obvious
things.

Also, are you interested to just write on ML what other people should do or you
want to help? If former, then please stop (because it is just disturbing and
not friendly). If latter, I'm happily will use script you have or you are going
to write.

Re: RPM packaging and ldconfig handling

By =?UTF-8?Q?Tomas... at 01/29/2018 - 15:46

On 29 January 2018 at 19:06, Igor Gnatenko < ... at fedoraproject dot org
Because similar changes even this one which you only recently started never
have been finished.
Don't get me wrong. You are doing great job. Method used so far in Fedora
are only wrong ..

I'm only asking to finish first what already have been started before you
will put on uour desk next mass change.

Also, are you interested to just write on ML what other people should do or
I've already wrote you in the ticket about remove icons caches updates that
remove desktop file cashes does not make any sense to start before remove
icons theme caches will be finished because quite often those updates are
in line above or below.
I'm simple waiting with raise next MCRs until prev changes will be finished.

I cannot help you on those changes because I have no proven packager privs.
If on next MCR you want me to deliver you list of patches and list of files
which needs to be applied on exact packages please do not force me or
people like me to do update those parches because someone else just after
generate thse patches made next batch of some past MCR changes still not
finishing those changes across all no touched specs.

As I wrote already I have at least few tenths other MCRs to discuss and
introduce but I refuse to cooperate in conditions when none of those
changes will be not really done from top to bottom. Is it now clear?
This is not about me or you. This is about GENERAL METHODOLOGY!!
We can do more together but you cannot just drop one change in the middle
and go to start another one ..
So again: please finish at lease PR 736 before you will start with ldconfig
to allow me start preparing next MCR when you will be working on ldconfig.

If you are taking care if exact MCR please clean everything around with
documentation and for example update rpmlint as well.
Such MCR coordinator does not need to do everything. Other people may help
him/her but this person should be at least coordinating everything and at
the and whole MCR checklist is in finished state.

This is like with with problems on taking care of the production issues or
faults.
Always needs to be someone who is controlling whole situation but this
person does not need to to person doing all OS, HW, app, db related things
which needs to be changed.
At the end such person in bigger organisation sometimes is taking
responsibility to teach other technical personnel about how to prevent
similar faults.

kloczek

Re: RPM packaging and ldconfig handling

By Tim Landscheidt at 01/29/2018 - 22:11

Unfortunately, progress in Fedora and similar projects is
not made by telling people what they are doing wrong, but by
doing The Right Thing™ yourself or in collaboration with
others. And even if one is reporting a fault, there are
ways to enable someone to fix that fault and there ways to
overwhelm them with superfluous information that makes their
work harder.

For example, take the first line of your text I quoted
above. I can tell you that you used "with" there twice, or
I can hide that nugget in a long diatribe about the English
language, HTML mail and whatever. If your time is limited,
you will probably prefer one over the other.

Or, to paraphrase perlstyle(1): Be explicit. Be concise. Be
nice.

Tim

Re: RPM packaging and ldconfig handling

By =?UTF-8?Q?Tomas... at 01/29/2018 - 23:07

On 30 January 2018 at 02:11, Tim Landscheidt <tim@tim-landscheidt.de> wrote:
[..]

OK. So if I'll be nice, explicit and concise it will cause that Igor will
finish at least one mass change before start another one?
Igor could you pleas confirm above?

kloczek

Re: RPM packaging and ldconfig handling

By Matthew Miller at 01/30/2018 - 08:32

On Tue, Jan 30, 2018 at 03:07:22AM +0000, Tomasz Kłoczko wrote:
Seriously, quit it. Igor doesn't work for you. Igor doesn't work for
me. Yet, he's actively working to make Fedora better and to improve our
packaging. That's awesome. An appropriate response might be: "Awesome!
Thanks for kicking off this effort. I see there's work to be done yet.
How can I help?"

Demanding that other people do things isn't the way we do things.

Re: RPM packaging and ldconfig handling

By =?UTF-8?Q?Tomas... at 01/30/2018 - 12:12

On 30 January 2018 at 12:32, Matthew Miller < ... at fedoraproject dot org>
wrote:

Who said that I'm demanding something?
Look one more time on <a href="https://pagure.io/packaging-committee/issue/736" title="https://pagure.io/packaging-committee/issue/736">https://pagure.io/packaging-committee/issue/736</a>
Igor took this tasks VOLUNTARILY and started working on necessary specs
before I've delivered batch of patches.
When I found that number of already done modifications is trashing already
many patches which I had prepared it was no sense to be (as me) involved in
helping finish this.
Now still is not finished about 20%.
Just please answer on the questions:
- Who will finish this?
- Why it is done so badly?
- What is the sense submitting more such mass changes if it is good chance
that they'll be not finished as well? (and now you are telling me that I'm
this bad guy because I've been showing those "naked pictures" to other
people)

kloczek

Re: RPM packaging and ldconfig handling

By Tim Landscheidt at 01/30/2018 - 13:21

You can help move this forward by publishing the script(s)
you used (or the patches that still apply cleanly if you
wrote them manually).

Also, just to state the obvious for most: This is some tidy-
ing up. It's good if it's done, but it is not blocking any-
thing. If someone already has patched "only" 20 % of the
specs, that is good, not bad, because the work to be done
has decreased by a fifth.

Tim

Re: RPM packaging and ldconfig handling

By =?UTF-8?Q?Tomas... at 01/30/2018 - 14:03

On 30 January 2018 at 17:21, Tim Landscheidt <tim@tim-landscheidt.de> wrote:
[..]

There is no any this kind script because ALL Fedora specs unstructured
formatting/indentations makes writing such scripts IMPOSSIBLE!!!
Because of this MOST of the changes per each package needs to be done
MANUALLY.
Is that CLEAR NOW?
How many times I must repeat this to punch kind of "mental helmet" people
like you?

Whole idea of the series mass changes was about aligning all specs to the
form when after many such iterations it will be possible to do more and
more other changes using simple sed regexps. NOW it is NOT POSSIBLE. Is
that clear now?

It is classic chicken and egg problem, and by proposing series of mass
cleanups I'm trying to cut this IMPOSSIBILITY loop.

Try to think why Igor already have done all changes in few batches just
going across all specs ALPHABETICALLY?
Answer: because each spec needs to be checked and modified MANUALLY!!!

And just for the record: again you did not answered on my questions
ignoring "en block" arguments and questions turning this thread again into
"ad hominem" conversation.
Again: my humble person has nothing to do with subject called "Fedora
methodology".

kloczek

Re: RPM packaging and ldconfig handling

By Igor Gnatenko at 01/29/2018 - 15:00

Hash: SHA256

On Mon, 2018-01-29 at 18:49 +0000, Tomasz Kłoczko wrote:
Redmining you 1000th time, don't mix issues. This thread is **ONLY about
ldconfig**.

Re: RPM packaging and ldconfig handling

By Igor Gnatenko at 01/14/2018 - 12:38

Hash: SHA256

On Fri, 2018-01-12 at 15:00 +0100, Florian Weimer wrote:
We can switch it to %filetrigger* at least for beginning in order to stop
asking people to write /sbin/ldconfig manually. Effect will be same, but at
least it will not put work on packagers heads.

It is possible to filter files in scriptlets to not run it on random files.

As Neal mentioned, it should be possible with very simple brp script.

As Jason pointed, he doesn't see value of having priority documented in
guidelines, it is just some value chosen by glibc (or, rather, by person who
sent PR)..

Since it doesn't hurt anyone, it can be done without update of guidelines.. But
Jason wrote that he will update it guidelines once he will get some free time.

Re: RPM packaging and ldconfig handling

By =?UTF-8?Q?Tomas... at 01/14/2018 - 19:13

On 14 January 2018 at 16:38, Igor Gnatenko
< ... at fedoraproject dot org> wrote:
I think that at least someone in glibc team should start to consider
drop completely use ld.so.cache.
This "speedup" mechanism was invented more than two decades ago when
it was the problem with VFS layer caching.
The same "loading time issues" have been driving in latex use kpathsea.
Both techniques today are more or less **obsolete**.

Other Unixes like BSD* and Solaris instead focusing on ld.so latency
started improving VFS caching and results now are equal from point of
view of execution latency
None of the BSD* or Solaris ld.so are using not using any ld.so. cache
and are using only more sophisticated configuration framework which
allows, for example, mask not use exact file which provides SONAME to
use another one which provides such SONAME from the non-standard
paths.
As result ld.so is not forced to load few hundreds KB cache file, it
stat()s and open()s blindly <libdir>/<SONAME> file relaying 100% of
VFS.

In other words instead of fighting with the fact that below
{,/usr}/lib{,64} or another subset of cases would be possible to drop
use ldconfig, simplify ld.so and at the end remove all %post/%postun
/sbin/ldconfig execution.
Instead, all of this could be introduced crle command like on Solaris.

crle man page <a href="https://docs.oracle.com/cd/E19109-01/tsolaris8/835-8001/6rutvdvik/index.html" title="https://docs.oracle.com/cd/E19109-01/tsolaris8/835-8001/6rutvdvik/index.html">https://docs.oracle.com/cd/E19109-01/tsolaris8/835-8001/6rutvdvik/index....</a>

Performance of the not use cache is easy to test by simple remove
/etc/ld.so.cache and observe ld.so by executing "LD_DEBUG=statistics
</something/to/execute>".
Example:

$ LD_DEBUG=statistics ls -d /etc
23174:
23174: runtime linker statistics:
23174: total startup time in dynamic loader: 6135538 cycles
23174: time needed for relocation: 2876398 cycles (46.8%)
23174: number of relocations: 629
23174: number of relocations from cache: 3
23174: number of relative relocations: 1582
23174: time needed to load objects: 2304750 cycles (37.5%)
/etc

If those statistics will be not enough probably other people will
propose other/better method showing that using ld.so.cache still is
necessary or could be dropped.

Solaris crle man page
<a href="https://docs.oracle.com/cd/E19109-01/tsolaris8/835-8001/6rutvdvik/index.html" title="https://docs.oracle.com/cd/E19109-01/tsolaris8/835-8001/6rutvdvik/index.html">https://docs.oracle.com/cd/E19109-01/tsolaris8/835-8001/6rutvdvik/index....</a>

[..]
BTW it is yet another small issue with those file triggers.
Build process described in glibc.spec build 32 or 64 bits versions of
the binaries.
ldconfig is part of the main glbc package and it is possible on x86
install glibc.i386 and glibc.x86_64
When both ABI versions packages are installed those file triggers will
be executed two times.
All this is result another rpm weakness that all global actions (aka
in rpm semantics triggers) must be defined not package manager set of
the trigger but only in packages.
Just for the compare .. IPS has the strict and finite set of analogues
of the triggers called actions.
***NONE*** of the packages definitions contains any actions
definitions and all works perfectly causing that whoever is
responsible for building packages has no opportunity to mess in this
area BY DEFINITION.
BTW .. IPS has no at all possibility to add any post/postun/trans
scripts. IMO it is only matter of time when rpm developers will spot
that all this stuff in spec files is only constant source of problems.
People moving away from SySV packages which implemented IPS come to
this brilliant observation DECADE ago. It may take on Linux next
decade to "reinvent the wheel" but I'm 100% that all those scripts
embedded in packages sooner or later will be removed.

Conclusion: so far I've been actively supporting add glibc file
triggers by trying to add my comments discussion in bugzilla tickets.
However, as I have in my head quite deep knowledge of other operating
systems recently I found see now WAY better solution which does not
increases current entropy and/or is Ockham Razor compliant solution
(<a href="https://en.wikipedia.org/wiki/Occam%27s_razor" title="https://en.wikipedia.org/wiki/Occam%27s_razor">https://en.wikipedia.org/wiki/Occam%27s_razor</a>)

So again this solution should consist of:
- remove use ld.so,cache by ld.so
- remove ldconfig and all /sbin/ldconfig in all spec files
- add crle or crle like command (knowing Linux NIH probably it will
end up on crle like command)

BTW: above could be introduced very quickly without touching glibc
code by simple /etc/ld.so.cahe and use ldconfig.

kloczek

Re: RPM packaging and ldconfig handling

By King InuYasha at 01/14/2018 - 19:32

On Sun, Jan 14, 2018 at 6:13 PM, Tomasz Kłoczko
<kloczko. ... at gmail dot com> wrote:
I'm not sure you're aware of this, but the GNU C Library serves more
than Linux. While Linux VFS is much better than it was 20 years ago,
other OSes are not necessarily so.

This is easy to fix. I could just do it using /%{_lib} and %{_libdir} instead.

It's pretty trivial to do that behavior. For example, we could just
have a posttrans trigger that runs a program that decides all the
things based on what the filesystem looks like (Solus does this with
usysconf[1]). But that means the tool needs to know how to decide what
to run.

[1]: <a href="https://github.com/solus-project/usysconf" title="https://github.com/solus-project/usysconf">https://github.com/solus-project/usysconf</a>

If we wanted less scriptlets in packages and singular set of triggers
across the board, it would technically be possible. But the penalty
for that is that the package manager must figure out how to evaluate
what to run. You don't get to get away from that logic.

This is not a particularly helpful comment. Solaris' crle is not
demonstratively better than current ldconfig configuration via drop in
directories. Personally, I prefer the latter because you can preload
search paths pretty trivially without requiring an execution
environment.

Re: RPM packaging and ldconfig handling

By =?UTF-8?Q?Tomas... at 01/15/2018 - 00:40

On 14 January 2018 at 23:32, Neal Gompa < ... at gmail dot com> wrote:
[..]
1) I'm not sure are you aware that C preprocessor (cpp) provides
possibility to use (or not) some parts of the C code conditionally
depends on OS type
2) Could you please name operating systems on which glibc is used NOW
which has no VFS or VFS like caching layer?
Linux has it.

We are trying discuss how to solve some Linux and rpm as package manager issues.
Please stick to this context only. We don't need to solve here Earth
famine problems (at least for now).

[..]
Nope. File triggers are using base paths. You cannot specify as the
parameters of those triggers /%{_lib}/lib*.so.* and
%{_libdir}/lib*.so.*
BTW: currently /%{_lib} and %{_libdir} are the same so only
%{_libdir} needs to be used.

$ ls -ld {,/usr}/lib{,64}
lrwxrwxrwx 1 root root 7 Dec 14 17:14 /lib -> usr/lib
lrwxrwxrwx 1 root root 9 Dec 14 17:14 /lib64 -> usr/lib64
dr-xr-xr-x. 1 root root 804 Jan 9 13:08 /usr/lib
dr-xr-xr-x. 1 root root 109892 Jan 14 03:21 /usr/lib64

In your case still rpm triggers semantics needs to changed or new
triggers type needs to be introduced.
In solution which I've described none of new code in rpm needs to be added.

Currently /sbin/ldconfig is part of the glibc package.
Depends which one package was installed/updated firs and which one
second system image end ups with 32 or 64 bits /sbin/ldconfig.
Depends which one binary will be present ldconfig by default goes over
/lib or /lib64 directories + any other directories specified in
/etc/ld.so,conf.d/ files.
To handle this case correctly it would be necessary to introduce
/sbin/ldconfig-{32,64} duplicate configuration files an not only
/etc/ld.so.cache but as well /var/cache/ldconfig/aux-cache file.

Just made some experiment:

[root@domek]# rpm -qf /sbin/ldconfig
glibc-2.26.9000-38.fc28.x86_64
[root@domek]# file /sbin/ldconfig
/sbin/ldconfig: ELF 64-bit LSB executable, x86-64, version 1
(GNU/Linux), statically linked, for GNU/Linux 3.2.0,
BuildID[sha1]=d6c3aae1d69c4ae9fe307ab58bbd2bc3f892bf38, not stripped
[root@domek]# dnf install -y glibc.i686
Last metadata expiration check: 2:47:52 ago on Mon 15 Jan 2018 01:15:04 GMT.
[..]

Installed:
glibc.i686 2.26.9000-38.fc28

Complete!

[root@domek]# file /sbin/ldconfig
/sbin/ldconfig: ELF 64-bit LSB executable, x86-64, version 1
(GNU/Linux), statically linked, for GNU/Linux 3.2.0,
BuildID[sha1]=d6c3aae1d69c4ae9fe307ab58bbd2bc3f892bf38, not stripped
[root@domek]# rpm -qf /sbin/ldconfig
glibc-2.26.9000-38.fc28.x86_64
[root@domek]# rpm -ql glibc.i686 | grep /sbin/ldconfig
/sbin/ldconfig
[root@domek]# rpm -ql glibc.x86_64 | grep /sbin/ldconfig
/sbin/ldconfig

This /sbin/ldconfig only is looking for libraries to index in /lib64.
With both glibc installed only 32 or 64 bit will be indexed does't
matter if in both glibcs will be file trigger only for /lib or /lib
and /lib64 or any other combinations of the paths.

In scenario which I've presented none of those things will happen
because it would be no ld.so.cache which context needs to be
maintained.
In your case to handle 32/64 ABI shared env it will be necessary to
introduce some number of new C code when in in my case complete
solution will consist almost entirely from only *remove existing code*
and on packaging layer remove (only) all ldconfig executions in rpm
scriplets.
(Again: .. Ockham Razor)

I can only repeat that after more than two decades when ld.so.cache
has been introduced now using this file only slows down run-time
linking.

Sorry, my comment was about package manager not universal configuration tool.

My comment was not about what "we wanted" or from point of view any
person views is possible or not.
I've only mentioned that some people analyzing existing cases caused
form conclusion that scriplets or pre/post installation custom are no
longer needed and 100% needs is possible to handle using finite set of
actions which could be HARD CODED into package manager.
Nevertheless this part is off-topic or out of the scope context which
we need to discuss here.
I've only covered yet another scenario not covered by what was up to
now discussed adding at the end .

Please do not continue commenting this part because is not relevant to
the scope of ld.s, ldconfig, ld.so.cacheand what needs to be done on
rpm specs area.

Sorry I don't get it.
Could you please show this on some example?
Are you sure what crle does and how ld.so on Solaris or BSD* is working?

kloczek

Re: RPM packaging and ldconfig handling

By Florian Weimer at 01/15/2018 - 08:42

On 01/15/2018 05:40 AM, Tomasz Kłoczko wrote:
I believe this part at least is not technically accurate, see
sysdeps/unix/sysv/linux/x86_64/dl-cache.h in the glibc sources. x86-64
ldconfig processes the lib and libx32 directories as well.

Thanks,
Florian

Re: RPM packaging and ldconfig handling

By =?UTF-8?Q?Tomas... at 01/15/2018 - 09:24

On 15 January 2018 at 12:42, Florian Weimer < ... at redhat dot com> wrote:
Just double checked this and you are right.
I've been doing my test when I had no installed any i686 package and
in case like this such test result looks a bit misleading:

[root@domek]# strace -e trace=file ldconfig 2>&1 | grep -v lib64
execve("/sbin/ldconfig", ["ldconfig"], 0x7ffe8c9d4260 /* 35 vars */) = 0
readlink("/proc/self/exe", "/usr/sbin/ldconfig", 4096) = 18
openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/etc/ld.so.conf", O_RDONLY) = 3
openat(AT_FDCWD, "/etc/ld.so.conf.d",
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 4
openat(AT_FDCWD, "/etc/ld.so.conf.d/atlas-x86_64.conf", O_RDONLY) = 4
openat(AT_FDCWD, "/etc/ld.so.conf.d/bind99-x86_64.conf", O_RDONLY) = 4
openat(AT_FDCWD, "/etc/ld.so.conf.d/community-mysql-x86_64.conf", O_RDONLY) = 4
openat(AT_FDCWD,
"/etc/ld.so.conf.d/kernel-4.13.9-300.fc27.x86_64.conf", O_RDONLY) = 4
openat(AT_FDCWD,
"/etc/ld.so.conf.d/kernel-4.14.11-300.fc27.x86_64.conf", O_RDONLY) = 4
openat(AT_FDCWD,
"/etc/ld.so.conf.d/kernel-4.15.0-0.rc7.git0.1.fc28.x86_64.conf",
O_RDONLY) = 4
openat(AT_FDCWD,
"/etc/ld.so.conf.d/kernel-4.15.0-0.rc7.git2.1.fc28.x86_64.conf",
O_RDONLY) = 4
openat(AT_FDCWD, "/etc/ld.so.conf.d/libiscsi-x86_64.conf", O_RDONLY) = 4
openat(AT_FDCWD, "/etc/ld.so.conf.d/wine-64.conf", O_RDONLY) = 4
stat("/lib", {st_mode=S_IFDIR|0555, st_size=804, ...}) = 0
stat("/libx32", 0x7ffd776af490) = -1 ENOENT (No such file or directory)
stat("/usr/lib", {st_mode=S_IFDIR|0555, st_size=804, ...}) = 0
stat("/usr/libx32", 0x7ffd776af490) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/var/cache/ldconfig/aux-cache", O_RDONLY) = 3
openat(AT_FDCWD, "/lib", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
lstat("/lib/sse2", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
openat(AT_FDCWD, "/lib/sse2", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/etc/ld.so.cache~",
O_WRONLY|O_CREAT|O_TRUNC|O_NOFOLLOW, 0600) = 3
chmod("/etc/ld.so.cache~", 0644) = 0
rename("/etc/ld.so.cache~", "/etc/ld.so.cache") = 0
stat("/var/cache/ldconfig", {st_mode=S_IFDIR|0700, st_size=18, ...}) = 0
openat(AT_FDCWD, "/var/cache/ldconfig/aux-cache~",
O_WRONLY|O_CREAT|O_TRUNC|O_NOFOLLOW, 0600) = 3
rename("/var/cache/ldconfig/aux-cache~", "/var/cache/ldconfig/aux-cache") = 0
+++ exited with 0 +++

After install glibc.i686 after stat() for /lib of course in above
output is new set of lines open()ing all libs in /lib.

Original (small) issue with place separated file triggers for /lib,
/ust/lib64 in 64 bit glibc and /lib, /usr/lib in 32 bit glibc packages
still is real because in such case
with installed two packages like glibc.{i686,x86_64} such separation
will cause that those file triggers will be called two times doing
*exactly* the same things in both cases.
It is not a big deal because with remove all per package
/sbin/ldconfig executions still it will save a lot of time .. however
fact is fact.
I've mentioned this duplicated execution only for the record and IMO
this can be ignored.

However still I think that the best solution would be drop use ld.so caches.

kloczek

Re: RPM packaging and ldconfig handling

By King InuYasha at 01/14/2018 - 12:25

On Fri, Jan 12, 2018 at 9:00 AM, Florian Weimer < ... at redhat dot com> wrote:
The fact that noarch Python site-packages exist in /usr/lib has always
bugged me. I don't know why it's that way or if there's something that
can be done about it in Fedora and upstream to move them to /usr/share.

But I don't think it's the only ecosystem like that, which is why they
are %transfiletriggers.

That said, in the nearly 10 years that the Mandriva family has been
using file triggers for running ldconfig, it hasn't caused any major
issues. Heck, the file triggers that have been proposed are more
comprehensive than the existing ones used in Mageia, to cover things
like the usage of RemovePathPostfixes in some RPM packages as well as
dealing with packages with non-standard paths.

Honestly, the worst case scenario is that "weird" packages going into
paths like /opt/foo/baz/lib64 would need to still run ldconfig, but
that's only if they don't drop a file into /etc/ld.so.conf.d and don't
use rpaths.

There's been a PR upstream in rpm[0] for a while now to support a more
comprehensive buildroot policy (brp) based on the Mandriva/Mageia
spec-helper[1] stuff.

One of the components of that PR is running ldconfig in the buildroot
to produce those DSO links[2].

We could pull that in and adjust redhat-rpm-config to disable the ones
we don't want. There's also an issue for making brp stuff better[3].

[0]: <a href="https://github.com/rpm-software-management/rpm/pull/122" title="https://github.com/rpm-software-management/rpm/pull/122">https://github.com/rpm-software-management/rpm/pull/122</a>
[1]: <a href="http://gitweb.mageia.org/software/rpm/spec-helper/" title="http://gitweb.mageia.org/software/rpm/spec-helper/">http://gitweb.mageia.org/software/rpm/spec-helper/</a>
[2]: <a href="https://github.com/rpm-software-management/rpm/pull/122/files#diff-c1bf327bbc4f83e504b1defa067006e0" title="https://github.com/rpm-software-management/rpm/pull/122/files#diff-c1bf327bbc4f83e504b1defa067006e0">https://github.com/rpm-software-management/rpm/pull/122/files#diff-c1bf3...</a>
[3]: <a href="https://github.com/rpm-software-management/rpm/issues/308" title="https://github.com/rpm-software-management/rpm/issues/308">https://github.com/rpm-software-management/rpm/issues/308</a>

In what sense do you want the priority value documented as? Do you
want it to be "no file trigger in Fedora can use a priority value
higher than this", or something else?

I think this is a really easy change to make.