8 a.m.
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
10:25 a.m.
On Fri, Jan 12, 2018 at 9:00 AM, Florian Weimer <fweimer(a)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:
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).
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-c1bf32...
[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.
--
真実はいつも一つ！/ Always, there's only one truth!
10:38 a.m.
-----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:
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).
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
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpbh6MACgkQaVcUvRu8
X0xsog//d/lBm90h6BZvq+ZvhZjO8Q96XeZzA8tvmxDAv6+98Z8bP0ZN4KK6Y1zX
zKYG7/s7gSke0yBrEkbbh6tMwkQcgBxRbU0JxIEKITFpaeVE3es9JvE79/S8aIFg
w2llNTOeP+yjcZ+i6e05ILZRW+RDY8bkZKSlsqHSO88tAQ+D65rgIeZur5OVDBT7
Sq1aqrHobOznD4lYTIK7EMHniLIJlh+lxRwiVkn6f0iM52UmG1uvpOu4VSFN6rBg
k3SMbiyxxuBrmfuD+mNOhc08N7fRzz2eOPr/srGXIag7OLrvMd6YVjtH68VWNIOa
9LIZHVSXdI0nGR19ri3qTOEf6ulY/dxfktc6sCCT/5m2zranL8Lk5R1s/PJHeJR5
m2JtoffhWhHHfp+T+LdgxDNSj34vtH1DANEheXO2MJPCvoDVB8kS8qVnEuoVHYhT
CxD74xQr0t/nb8sfRFptFV4d+MB6Rnc4bvLNQUTBar61Kk47JmtLl7vsdRevWvKB
gtTD8IKrou6nMs9EhYO1K9vs/8zttDsB2hjSAlC3l4m58v3PL6IFmtII9usfXgH3
Cqa2+HlmvC9LLXZSQruFmaHZLK1OI/F7WCGoGZFzwH0C7s4eUwurAvBhF/JJfb+4
ncDT5l7QExD82rgM556iGPg0n+YSaA3ChZz2SbYZ9Z1jSNVZDsU=
=kuPx
-----END PGP SIGNATURE-----
5:13 p.m.
On 14 January 2018 at 16:38, Igor Gnatenko
<ignatenkobrain(a)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:
>
> 1. 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
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
5:32 p.m.
On Sun, Jan 14, 2018 at 6:13 PM, Tomasz Kłoczko
<kloczko.tomasz(a)gmail.com> wrote:
On 14 January 2018 at 16:38, Igor Gnatenko
<ignatenkobrain(a)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:
>>
>> 1. 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.
--
真実はいつも一つ！/ Always, there's only one truth!
10:40 p.m.
On 14 January 2018 at 23:32, Neal Gompa <ngompa13(a)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.
[1]: https://github.com/solus-project/usysconf
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
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
6:42 a.m.
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
7:24 a.m.
On 15 January 2018 at 12:42, Florian Weimer <fweimer(a)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
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
11:18 a.m.
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
12:49 p.m.
On 29 January 2018 at 17:18, Florian Weimer <fweimer(a)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
--
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH <http://lnkd.in/FXPWxH>*
1 p.m.
-----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(a)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 SIGNATURE-----
iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpvb0YACgkQaVcUvRu8
X0wknxAAq3lIUPqHp86ANwS3fw3jlJBdCXjTNRVuxENg+1RsmC9ABNyxeig87o89
6t45hJSPA6Jq7w5DbTrNOm4Qpxw1ldRHeWxp6yxJw6qmmB8egPwrK20FzjQ1gELN
i+IoaQ2lu3aLS1VQBsEAiCYPco/Vw5JxRHge3AqzS4lS9VChH+wadfchjZAnWDv1
Q5etY2LP9P1qe0G0HnCKAPOQPQH4b0BAuRA6OTjaSRpahD/JKHsZDJHFOkVx9vEL
yshsAnwM2oiapUieytc1svEwQVd87DD/Wn3S0TbRynUALacz25X0xpfnRLwZLMBm
kiES8tCMBwesmoLwsuZhBSWM8VQYVqOfJ6EI1GRByj8p/tFMu44QduzgOqNJ8qKF
vyk0xJ0aTCXrux6Z42aPWBZJeQAz7TUHUeTUbyJxdeqPwZJkRx9vxgommcBIjN1u
P7sopGuFRLZfldut3DABtlwuiFDbQo4QZqPQaApLM6z4o7u5WURkLYvP9g1Qvuha
LLftGqm/JpOtNcLz2FbP+MP4aa8t5vky2TdwpBkKNv2DWcKu2XjeQm67GzA4Rp9N
kNzk39wEfECCL3hQN9/ah4MZzjb8DXbbXoPo/sIPOA8dQZFf84DxJXggLnzoiIW+
IpbJS+tjYKUt6bfsNKeVp3CA198YDhkjXTZlntKEXeTxCEumDRs=
=aJ8N
-----END PGP SIGNATURE-----
1:06 p.m.
-----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(a)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
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpvcMkACgkQaVcUvRu8
X0zJYg//SRQTzH5njmIlCtAzTNE0I9TB/TDAzf0pQOZ2uTJgrz1jp7TMod0CJm5q
c20cBAEvJSVESS9kLvZxHVsv8k8gB5kIn85lc3miXvu1NUZbZy/K+ENw/twINkZG
v/mXkVeofSUWvo5qH40LV1KT0GgRPFiczZ9GLMos+GMtRFmky6LtfG/CE8NS0GS2
MH3ogWMIa4trVN+a+qqslaV8CuWhibOKlBMmhGlJFJL+Wg65qlkya8uOwtHWyri7
/a5BLoIt4Tx7zR6DgHLfz0Xv6QvcxzpD8E8OTs8mC+dNaQ+OEaGe7GstwUUgdDFH
TGJEX74Up7xFc6ebrlacj0U27kftAVL+XAdPVAcEox5ASDojOzmaTtMJy2hfev2b
nR1BXV/a2bEgdezM7rFeKCvf6olU+5OeZoNJJpVhkWGbmcOiBx4QWF9Ynow14Z3r
wJ0yCteh7uAqypZzQsPZ5fFuLb6SiWQ+mXcfxeO1+jLk1EjNyD9MYK5kZ4rGTFFt
ORUb0LGCZOAQ7KtXbP/ulEaNrw34rCyCF8xaHwGYFtrDUbx63YfDZ7nE1SLwNJzn
/UKUeG/j34L0T52Sy1Ntk3XuEhns/Yw1jTA95iLwaufQ7z1TCBS/cX/JqKX7DO1D
DuDXUMQoZwTUtDs4gF2kxZFSfBlrt9LrqII0/g6rEPQaSfGY83Y=
=pj/r
-----END PGP SIGNATURE-----
1:46 p.m.
On 29 January 2018 at 19:06, Igor Gnatenko <ignatenkobrain(a)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 | LinkedIn: *http://lnkd.in/FXPWxH <http://lnkd.in/FXPWxH>*
8:11 p.m.
Tomasz Kłoczko <kloczko.tomasz(a)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
9:07 p.m.
On 30 January 2018 at 02:11, Tim Landscheidt <tim(a)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
--
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH <http://lnkd.in/FXPWxH>*
6:32 a.m.
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.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
10:12 a.m.
On 30 January 2018 at 12:32, Matthew Miller <mattdm(a)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 | LinkedIn: *http://lnkd.in/FXPWxH <http://lnkd.in/FXPWxH>*
11:21 a.m.
Tomasz Kłoczko <kloczko.tomasz(a)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
12:03 p.m.
On 30 January 2018 at 17:21, Tim Landscheidt <tim(a)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
--
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH <http://lnkd.in/FXPWxH>*
2:02 a.m.
~~~
+ /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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
2:15 a.m.
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
2:22 a.m.
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(a)redhat.com> - 2.5.0-88
+- Drop obsolete ldconfig scriptlets.
+
* Tue Jan 09 2018 Vít Ondruch <vondruch(a)redhat.com> - 2.5.0-87
- Fix segfaults during generating of documentation.
~~~
Vít
2:57 a.m.
-----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
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpwM4MACgkQaVcUvRu8
X0wmKg/9EpqqwJ+uG3dVB4NhktxUS/MFZdh1eAw31YyxYTZROg61UnwGFfwi3yDB
mjpoTvckrgQnsYqa9NkUqrZ4/b7hKgEHJn5Gv6k//sGEHL85mStHfTz/9Ada/Xf1
mIdKI6OnIiYZCUeBzN3bA7YQbb9a1xeFj+Jd7A/rwmDAXfYNKtAWhyXwGCGDYflQ
68xcL1yE9EKRvJ5gYPl1/JeipwNcBe9ztmLooDhCVXb/4eRNaC7NP84QRDgh23hB
EDC8KhP2kQWHpKHEWI3irqwFK4i+WjtgDVMi4u/wSdtw9dAhm/jiEgI8nqQS+o3A
j02hCDxgbTx6uhxFDM5RaEbm9H4QMy7FwwOFc4I8YVqIsorRk/va50rQYqYY9iu/
EzSn2UK6xkltwBs2xi/6IRNfCvt+wHcOK4c8u20Nr/yxBl+n0AvbrFntPiIyoaKD
9PWySte92oa2kP8JSdh4xZlE+IpZkW6oPLh2rwaRMriAuZNFKeUSQceQCUjO8mFe
QVzjFjuwhOv7V7xMXZiSiEVt1LAren5Nt88WxWOyG4LRqJz87+oDfkzFijmtFgWD
YxTybfvgQRM3ZkUb02SbvKyFD82kCeXnf2Dr387Dr3AKQyIlqfpdFvCRwyb4Vc72
djsZkGgaUK87i4qLxbQRUpgM56U+ZZKV9+SBfRc1ipHwcRh/JXs=
=DCoF
-----END PGP SIGNATURE-----
3:01 a.m.
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
6:01 a.m.
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
6:06 a.m.
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
6:17 a.m.
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
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
6:54 a.m.
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
7 a.m.
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
7:06 a.m.
-----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
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpxv1IACgkQaVcUvRu8
X0z7xw/9F44a2CewhQEMC1u52IVXMl4KvI2dvn9uNTWRA2f0PR1VZ4gLxaycrKKC
mx7p87FaFYpYFqIm2p0iITcjA1gu3ejVfCzHI+I3Bb0I90VlM0rV7U2s2E8TvoNO
i4Wr1c+gMn5boVAqPeO6D1Wk8jWz4ka0zsdsJ7PbhBt/2N3ITMs0Byxg072HYy7V
Ly8ztJyHONIYFCYi9exqWZcgeTihuNsMro8TFjQ60RApCaSeY/cEIRN+C8yuiee8
Q8BQWyE4b0nBHgLwLFAx+UHbO9Rt85wZGRsKOtJhtAAdOWq0w90GZedYgPuq0Y95
YAUCm8uSeBr328eRKOI6usdAJOwqz/B/hA7cSu12xD8leo7MAQjJhhfHaKTJIXAc
/5gCHUVGSuZjjB/+Alg6Fwe5ggQCtQz5rKHPtHyRL8JjDo/DecK8jtEcVAaSaJiJ
BMWlF1ZmMZS8GBJEinV/atyxGUIxv/huO3np8G6ThnwfcK+giIiAvFStkyap5mbv
yjrnKU+hOOnFTdiKrbuhIDqRIIjcxDUlEdz9vV5LNR0DOqW7hMR2CTV/CWmLZEck
XMCCPGmBsdmFKQ2smdIF6dMz+xG36E8IjbdKKd7LhBtGcL104PLLA4H3HkB9/ItJ
rvcA4ySTvF1YfNP0HuVMcTeJYzrxkG9YvPDymK/sjqQVKt1BIc0=
=em37
-----END PGP SIGNATURE-----
7:53 a.m.
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
7:55 a.m.
-----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 SIGNATURE-----
iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpxyuQACgkQaVcUvRu8
X0yNURAAvoM8dUhwc4godVoc7O5y7t41JUijeDkhBLzSQSouUwAIefeaNWqO2Wr4
fy4TBY7A4piyKlwXdGsmjh7GGpwl3l623zoaqaugL/8hs8212JVelFQs7WhE6d2r
s6sMsy5Y9spue8FpT+rQ8Tn+Qaqyeo9ZCHfo5xUrvSj/YeEyWTssZa7XWjPNHb5h
Loy4n8kivD2tq+ycAIx+3w6+U1DsyRvhYUmQy/DwfegLy5TSuybf2ott42mZLy5k
WkEHZZ/gJnIMuW0Ra+E2unN7zpeKnC6Eg+ss0mhBb33C0WXLtZvWCHLxTrliheuy
Bn5+aGpf01zCev2r9/iK91/MR1ZtCxPMK7/P68qEQ4RoCrGUT3GtBBuSQ9MzFqge
If8lFHVYSfNKpdzSBLTlwB+2ONcStylA1jUg9MiSRN6anH5867pJvTF+4iGOWfn6
E2yf4IA57p//xGH5LIoXKMMCYWt5bcVnydxnznEHwGYBKAQgk9/4eBhkGSHZBJAQ
qAUC/V9SXuvFNW8c77sJKBlPXirFRIdBa/whHzyGKwBDAqCCW6h0r2yFQ84pmVYF
5xFZpkWdMOBbAa1Rz2NqojfoJqz8b4YGkPtYGve3TZ/nqoDr/wxpiKsobV4oOK63
aAgQh+bk1UD+9HqLOcxuPFRYnxWeTb9Vo0QBjk8IN7Fkt2A6goQ=
=1OCS
-----END PGP SIGNATURE-----
7:03 a.m.
-----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
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpxvrgACgkQaVcUvRu8
X0z61A//an3YDqsC86tA1VCWMgx7gDSutV3eXS1SkvYWGu+h9MlZRTQmoa9alpDd
FFZrYnxt77ln71IvOF+IAhL1MxbwFmkPAU8n9+q6o3jVH1wN8F5iRNzqjyX91StA
Ib/YK781/Bjk4SflsULmqb5sCANeTr1Qb0W4JEd9mE0iGSVZTJ03DC5jheZKw3Lf
UcPaI3jPHv7wztZ6TRzf0abr2e6o77gkYggkC9qq2bZ/XnTUbCsV/82seiF0wwK2
+x1tQLeDFQf+SMJo5WnB4wX1oh/sQBYPEzsbzFaMCCRHY5R21xmYqtM8lXVC2EzW
S2cZ36IsxqljbFR7U3W5TNPZdROTiDEE24Bh1ztZaDx/CG9x65hyb6tbJCuzikPw
HajJjmODcKfsXXESoXGFJ4FQknMkXyCWa8M1HKhTFnR8oeNymbSn2dMEudBWiIQv
SU3NhYjxOkLvPKnXt7JAgXDysNwflEjje8QfvAUFpxAvOAMtBDoNnPfp2si67sMS
sI+iQaF/CBFLYQRqQdFCiPASMUk6H7myeh2/3w/0yjG4tC6gpU7kWa5bvLReZUNU
lVCnhMETnGLbmwMKmZzfg4ARZTeN9BX5vtnMpaxb6Yc3ypfPu4B0YPNA12U1+xKp
CbJsfB09lVOBVGvJVxG8TC6AwgYRAWwLkHoJT57cygOL1Kfvtv0=
=fbEP
-----END PGP SIGNATURE-----
7:14 a.m.
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
7:38 a.m.
-----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:
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?
tibbs is working on updating guidelines[0].
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).
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
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpxxukACgkQaVcUvRu8
X0xmuw/8CczKI4GTPB++G4Nep1g3vw2CW9X6Nc2TaukNsGD6QAIIgxbmV5xwVpbX
c1IzAsjl2Zln9ft51hwrnxfOqh69lGOUWFeNmzCaRjU1UoHZ6yx96FNuytuJttcb
Jd9eqsXtfus2LS8oaePulg1k4lbdVHowrvR03U3rRKY6Z6udtcwIihJXaxJ6LIVA
X5Wn1wp3v99Xkk5kRwaYM9Xx38x9kX/wayAdeVW8DD6CtYJorhpMYajGXXzuCwR4
ic1S/EXQnQg+lSZjbhzvdtwsDVgYAdNs0KoOWcrC7RbeG8kSz81iG4jMVZYeVImH
vqbsy3mE6i7noG7Bo4vFX0JZ5yMPXp+pON2ifvU1ZXlDdxfxpqlOL27AFz9HKrzM
jiCvHHBg4fOrLMX/rR1cSqV95jxg0Dfpcih9OKkV+SRKORebCYocpb0ljzuT34pu
Ay1FTFtHhCpFT3e/rgv3hgS0YygWW7iHMTz8QCNM8cN6JfO5EoVc0PJQY5wZtH+f
EbFtTUTd8r81QxEB9TKoVcevsiEXhf65WEbmD5sSqWBfVsi6MY7lALZGU32EbKx4
WdOYVHIxQK8AO0mMnimM3V1osLEhZFERASy137YncKNL5OXbsuS8tzAiShqANwVv
sejFhUqBOo+DGeycRgQrRoziLClZpQlUISRIkkMDFbL1W5PgGwU=
=FiJi
-----END PGP SIGNATURE-----
7:41 a.m.
On Wed, Jan 31, 2018 at 7:38 AM, Igor Gnatenko <
ignatenkobrain(a)fedoraproject.org> wrote:
> 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).
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
7:40 a.m.
On Wed, Jan 31, 2018 at 8:14 AM, Richard Shaw <hobbes1069(a)gmail.com> wrote:
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?
New guidelines are being drafted:
https://pagure.io/packaging-committee/issue/654
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).
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.
--
真実はいつも一つ！/ Always, there's only one truth!
2276
days inactive
2295
days old
36 comments
10 participants
participants (10)
-
Florian Weimer -
Igor Gnatenko -
Kamil Dudka -
Matthew Miller -
Neal Gompa -
Richard Shaw -
Tim Landscheidt -
Tom Hughes -
Tomasz Kłoczko -
Vít Ondruch