The glibc team has received a request to change the way ldconfig invocations during package installations and deinstallations are handled.
https://src.fedoraproject.org/rpms/glibc/pull-request/5 https://bugzilla.redhat.com/show_bug.cgi?id=1380878
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:
https://fedoraproject.org/wiki/Packaging:Guidelines#Shared_Libraries
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
On Fri, Jan 12, 2018 at 9:00 AM, Florian Weimer fweimer@redhat.com wrote:
The glibc team has received a request to change the way ldconfig invocations during package installations and deinstallations are handled.
https://src.fedoraproject.org/rpms/glibc/pull-request/5 https://bugzilla.redhat.com/show_bug.cgi?id=1380878
Some background: ldconfig serves several functions. Key aspects are:
Speed up programing loading.
Enable the dynamic linker to load libraries by their soname.
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:
https://fedoraproject.org/wiki/Packaging:Guidelines#Shared_Libraries
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).
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.
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).
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]: https://github.com/rpm-software-management/rpm/pull/122 [1]: http://gitweb.mageia.org/software/rpm/spec-helper/ [2]: https://github.com/rpm-software-management/rpm/pull/122/files#diff-c1bf327bb... [3]: https://github.com/rpm-software-management/rpm/issues/308
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 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?
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.
I think this is a really easy change to make.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On Fri, 2018-01-12 at 15:00 +0100, Florian Weimer wrote:
The glibc team has received a request to change the way ldconfig invocations during package installations and deinstallations are handled.
https://src.fedoraproject.org/rpms/glibc/pull-request/5 https://bugzilla.redhat.com/show_bug.cgi?id=1380878
Some background: ldconfig serves several functions. Key aspects are:
Speed up programing loading.
Enable the dynamic linker to load libraries by their soname.
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:
https://fedoraproject.org/wiki/Packaging:Guidelines#Shared_Libraries
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).
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 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).
It is possible to filter files in scriptlets to not run it on random files.
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).
As Neal mentioned, it should be possible with very simple brp script.
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.
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)..
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.
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. - -- - -Igor Gnatenko
On 14 January 2018 at 16:38, Igor Gnatenko ignatenkobrain@fedoraproject.org wrote:
On Fri, 2018-01-12 at 15:00 +0100, Florian Weimer wrote:
The glibc team has received a request to change the way ldconfig invocations during package installations and deinstallations are handled.
https://src.fedoraproject.org/rpms/glibc/pull-request/5 https://bugzilla.redhat.com/show_bug.cgi?id=1380878
Some background: ldconfig serves several functions. Key aspects are:
- Speed up programing loading.
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 https://docs.oracle.com/cd/E19109-01/tsolaris8/835-8001/6rutvdvik/index.html
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 https://docs.oracle.com/cd/E19109-01/tsolaris8/835-8001/6rutvdvik/index.html
[..]
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
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 (https://en.wikipedia.org/wiki/Occam%27s_razor)
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
On Sun, Jan 14, 2018 at 6:13 PM, Tomasz Kłoczko kloczko.tomasz@gmail.com wrote:
On 14 January 2018 at 16:38, Igor Gnatenko ignatenkobrain@fedoraproject.org wrote:
On Fri, 2018-01-12 at 15:00 +0100, Florian Weimer wrote:
The glibc team has received a request to change the way ldconfig invocations during package installations and deinstallations are handled.
https://src.fedoraproject.org/rpms/glibc/pull-request/5 https://bugzilla.redhat.com/show_bug.cgi?id=1380878
Some background: ldconfig serves several functions. Key aspects are:
- Speed up programing loading.
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**.
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.
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 https://docs.oracle.com/cd/E19109-01/tsolaris8/835-8001/6rutvdvik/index.html
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 https://docs.oracle.com/cd/E19109-01/tsolaris8/835-8001/6rutvdvik/index.html
[..]
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
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.
This is easy to fix. I could just do it using /%{_lib} and %{_libdir} instead.
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.
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]: https://github.com/solus-project/usysconf
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.
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.
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 (https://en.wikipedia.org/wiki/Occam%27s_razor)
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)
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.
On 14 January 2018 at 23:32, Neal Gompa ngompa13@gmail.com 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**.
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.
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).
[..]
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.
This is easy to fix. I could just do it using /%{_lib} and %{_libdir} instead.
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.
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.
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.
Sorry, my comment was about package manager not universal configuration tool.
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.
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.
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.
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 (https://en.wikipedia.org/wiki/Occam%27s_razor)
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)
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.
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
On 01/15/2018 05:40 AM, Tomasz Kłoczko wrote:
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.
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
On 15 January 2018 at 12:42, Florian Weimer fweimer@redhat.com wrote:
On 01/15/2018 05:40 AM, Tomasz Kłoczko wrote:
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.
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.
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
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
On 29 January 2018 at 17:18, Florian Weimer fweimer@redhat.com wrote:
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.
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On Mon, 2018-01-29 at 18:49 +0000, Tomasz Kłoczko wrote:
On 29 January 2018 at 17:18, Florian Weimer fweimer@redhat.com wrote:
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.
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:
Redmining you 1000th time, don't mix issues. This thread is **ONLY about ldconfig**. - -- - -Igor Gnatenko
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On Mon, 2018-01-29 at 18:49 +0000, Tomasz Kłoczko wrote:
On 29 January 2018 at 17:18, Florian Weimer fweimer@redhat.com wrote:
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.
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.
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. - -- - -Igor Gnatenko
On 29 January 2018 at 19:06, Igor Gnatenko <ignatenkobrain@fedoraproject.org
wrote:
[..]
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.
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.
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
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.
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
Tomasz Kłoczko kloczko.tomasz@gmail.com wrote:
[…]
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.
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
On 30 January 2018 at 02:11, Tim Landscheidt tim@tim-landscheidt.de wrote: [..]
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.
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
On Tue, Jan 30, 2018 at 03:07:22AM +0000, Tomasz Kłoczko 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?
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.
On 30 January 2018 at 12:32, Matthew Miller mattdm@fedoraproject.org wrote:
On Tue, Jan 30, 2018 at 03:07:22AM +0000, Tomasz Kłoczko 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?
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.
Who said that I'm demanding something? Look one more time on https://pagure.io/packaging-committee/issue/736 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
Tomasz Kłoczko kloczko.tomasz@gmail.com wrote:
[…]
Who said that I'm demanding something? Look one more time on https://pagure.io/packaging-committee/issue/736 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)
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
On 30 January 2018 at 17:21, Tim Landscheidt tim@tim-landscheidt.de wrote: [..]
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).
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
~~~
+ /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):
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 _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
On 01/30/2018 09:02 AM, Vít Ondruch wrote:
+ /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?
Context? ldconfig definitely shouldn't print /etc/ld.so.conf.
Thanks, Florian
Dne 30.1.2018 v 09:15 Florian Weimer napsal(a):
On 01/30/2018 09:02 AM, Vít Ondruch wrote:
+ /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?
Context? ldconfig definitely shouldn't print /etc/ld.so.conf.
Thanks, Florian
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 - -%postun libs -p /sbin/ldconfig - %files %license BSDL %license COPYING @@ -1062,6 +1058,9 @@ make check TESTS="-v $DISABLE_TESTS" %{gem_dir}/specifications/xmlrpc-%{xmlrpc_version}.gemspec %changelog +* Tue Jan 30 2018 Vít Ondruch vondruch@redhat.com - 2.5.0-88 +- Drop obsolete ldconfig scriptlets. + * Tue Jan 09 2018 Vít Ondruch vondruch@redhat.com - 2.5.0-87 - Fix segfaults during generating of documentation. ~~~
Vít
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On Tue, 2018-01-30 at 09:02 +0100, Vít Ondruch wrote:
+ /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?
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. - -- - -Igor Gnatenko
On 01/30/2018 09:57 AM, Igor Gnatenko 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.
But why does it print /etc/ld.so.conf, and not the path in the buildroot? That concerns me.
Thanks, Florian
Dne 30.1.2018 v 10:01 Florian Weimer napsal(a):
On 01/30/2018 09:57 AM, Igor Gnatenko 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.
But why does it print /etc/ld.so.conf, and not the path in the buildroot? That concerns me.
I would be concerned even if it issued warning about /etc/ld.so.conf in buildroot ...
Vít
On 01/30/2018 01:01 PM, Vít Ondruch wrote:
Dne 30.1.2018 v 10:01 Florian Weimer napsal(a):
On 01/30/2018 09:57 AM, Igor Gnatenko 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.
But why does it print /etc/ld.so.conf, and not the path in the buildroot? That concerns me.
I would be concerned even if it issued warning about /etc/ld.so.conf in buildroot ...
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
On 30/01/18 12:06, Florian Weimer wrote:
On 01/30/2018 01:01 PM, Vít Ondruch wrote:
Dne 30.1.2018 v 10:01 Florian Weimer napsal(a):
On 01/30/2018 09:57 AM, Igor Gnatenko 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.
But why does it print /etc/ld.so.conf, and not the path in the buildroot? That concerns me.
I would be concerned even if it issued warning about /etc/ld.so.conf in buildroot ...
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.
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
On Tuesday, January 30, 2018 9:57:39 AM CET Igor Gnatenko 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. -- -Igor Gnatenko
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
On 01/31/2018 01:54 PM, Kamil Dudka wrote:
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?
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On Wed, 2018-01-31 at 14:00 +0100, Florian Weimer wrote:
On 01/31/2018 01:54 PM, Kamil Dudka wrote:
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?
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.
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. - -- - -Igor Gnatenko
On Wednesday, January 31, 2018 2:00:08 PM CET Florian Weimer wrote:
On 01/31/2018 01:54 PM, Kamil Dudka wrote:
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?
I think in this situation, you need to disable this feature using:
%undefine __brp_ldconfig
Thank both of you for the suggestion! It has indeed resolved the problem.
Depending on whether you can include the appropriate symbolic links in the packages themselves,
Those symlinks are created by libtool, so I believe they are appropriate.
you can or cannot remove the explicit ldconfig calls.
%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
I don't think it's feasible or even desirable to teach ldconfig about the RemovePathPostfixes RPM feature.
Thanks, Florian
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On Wed, 2018-01-31 at 14:53 +0100, Kamil Dudka wrote:
On Wednesday, January 31, 2018 2:00:08 PM CET Florian Weimer wrote:
On 01/31/2018 01:54 PM, Kamil Dudka wrote:
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?
I think in this situation, you need to disable this feature using:
%undefine __brp_ldconfig
Thank both of you for the suggestion! It has indeed resolved the problem.
Depending on whether you can include the appropriate symbolic links in the packages themselves,
Those symlinks are created by libtool, so I believe they are appropriate.
you can or cannot remove the explicit ldconfig calls.
%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?
If you don't simply merge master branch to others, then yes. Otherwise, you should consider using macro we've created.
%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
%ldconfig_scriptlets -n libcurl %ldconfig_scriptlets -n libcurl-minimal - -- - -Igor Gnatenko
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On Wed, 2018-01-31 at 13:54 +0100, Kamil Dudka wrote:
On Tuesday, January 30, 2018 9:57:39 AM CET Igor Gnatenko 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. -- -Igor Gnatenko
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?
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. - -- - -Igor Gnatenko
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On Wed, 2018-01-31 at 07:14 -0600, Richard Shaw wrote:
I re-skimmed the whole thread so I apologize if I missed it, but I have a couple of questions:
- 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?
tibbs is working on updating guidelines[0].
- 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).
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] https://pagure.io/packaging-committee/issue/654 - -- - -Igor Gnatenko
On Wed, Jan 31, 2018 at 7:38 AM, Igor Gnatenko < ignatenkobrain@fedoraproject.org> wrote:
- 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).
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.
Thanks for clearing that up for me!
Richard
On Wed, Jan 31, 2018 at 8:14 AM, Richard Shaw hobbes1069@gmail.com wrote:
I re-skimmed the whole thread so I apologize if I missed it, but I have a couple of questions:
- 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?
New guidelines are being drafted: https://pagure.io/packaging-committee/issue/654
- 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).
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.