All,
I sent the httrack package to security a couple weeks ago. It builds, but with a few rpmlint issues.
I thought I would clean up the one about the shared library needing to be split out to its own package.
I've tried to do that in home:gregfreemyer:branches:security > httrack
The diff is: https://build.opensuse.org/package/rdiff?opackage=httrack&oproject=secur...
I've tried multiple ways to call ldconfig.
But my build always fails with:
[ 218s] libhttrack2.x86_64: E: library-without-ldconfig-postin (Badness: 300) /usr/lib64/libhtsjava.so.2.0.46 [ 218s] libhttrack2.x86_64: E: library-without-ldconfig-postin (Badness: 300) /usr/lib64/libhttrack.so.2.0.46 [ 218s] This package contains a library and provides no %post scriptlet containing a [ 218s] call to ldconfig.
The spec file currently has: === %post /sbin/ldconfig /usr/lib64
%postun /sbin/ldconfig /usr/lib64 ===
I've tried the basic versions as well.
== %post -p /sbin/ldconfig %postun -p /sbin/ldconfig == %post /sbin/ldconfig %postun /sbin/ldconfig ==
Can anyone tell me what's going on?
Thanks Greg
On Mon, 2012-09-10 at 17:05 -0400, Greg Freemyer wrote:
All,
I sent the httrack package to security a couple weeks ago. It builds, but with a few rpmlint issues.
I thought I would clean up the one about the shared library needing to be split out to its own package.
I've tried to do that in home:gregfreemyer:branches:security > httrack
The diff is: https://build.opensuse.org/package/rdiff?opackage=httrack&oproject=secur...
I've tried multiple ways to call ldconfig.
But my build always fails with:
[ 218s] libhttrack2.x86_64: E: library-without-ldconfig-postin (Badness: 300) /usr/lib64/libhtsjava.so.2.0.46 [ 218s] libhttrack2.x86_64: E: library-without-ldconfig-postin (Badness: 300) /usr/lib64/libhttrack.so.2.0.46 [ 218s] This package contains a library and provides no %post scriptlet containing a [ 218s] call to ldconfig.
You need to move the ldconfig call to the libhttrack2 sub package:
%post -n libhttrack2 -p /sbin/ldconfig %postun -n libhttrack2 -p /sbin/ldconfig
%post without -n <name> implies having the post on the main package; which in your case does not need it, as the lib lives in a sub - package.
Hth, Dominique
El 10/09/12 18:08, Dimstar / Dominique Leuenberger escribió:
You need to move the ldconfig call to the libhttrack2 sub package:
%post -n libhttrack2 -p /sbin/ldconfig %postun -n libhttrack2 -p /sbin/ldconfig
%post without -n <name> implies having the post on the main package; which in your case does not need it, as the lib lives in a sub - package.
Hth, Dominique
That being said, I wonder why we still need this in the first place, will it be possible to teach the linker to "keep an eye" on libraries already in the cache with inotify and rebuild it automagically when needed ?
On Monday, September 10, 2012 18:38:57 Cristian Rodríguez wrote:
El 10/09/12 18:08, Dimstar / Dominique Leuenberger escribió:
You need to move the ldconfig call to the libhttrack2 sub package:
%post -n libhttrack2 -p /sbin/ldconfig %postun -n libhttrack2 -p /sbin/ldconfig
%post without -n <name> implies having the post on the main package; which in your case does not need it, as the lib lives in a sub - package.
Hth, Dominique
That being said, I wonder why we still need this in the first place, will it be possible to teach the linker to "keep an eye" on libraries already in the cache with inotify and rebuild it automagically when needed ?
You don't need it - the dynamic linker ld.so, e.g. on x86-64 it is /lib64/ld-linux-x86-64.so.2, will first check the cache and then check the filesystem.
Invoking ldconfig from ld.so would be really bad - and implementing ldconfig as a daemon is also not worth it.
Still, library searching is costly and thus we require the ldconfig as an optimiziation.
Btw. if you want to see how libraries are searched run for example: LD_DEBUG=libs /bin/ls
Need help? LD_DEBUG=help /bin/ls
Andreas
On Tue, Sep 11, 2012 at 09:31:21AM +0200, Andreas Jaeger wrote:
On Monday, September 10, 2012 18:38:57 Cristian Rodríguez wrote:
El 10/09/12 18:08, Dimstar / Dominique Leuenberger escribió:
You need to move the ldconfig call to the libhttrack2 sub package:
%post -n libhttrack2 -p /sbin/ldconfig %postun -n libhttrack2 -p /sbin/ldconfig
%post without -n <name> implies having the post on the main package; which in your case does not need it, as the lib lives in a sub - package.
Hth, Dominique
That being said, I wonder why we still need this in the first place, will it be possible to teach the linker to "keep an eye" on libraries already in the cache with inotify and rebuild it automagically when needed ?
You don't need it - the dynamic linker ld.so, e.g. on x86-64 it is /lib64/ld-linux-x86-64.so.2, will first check the cache and then check the filesystem.
Invoking ldconfig from ld.so would be really bad - and implementing ldconfig as a daemon is also not worth it.
Hallo,
you don't need to do so - all you need is to have proper systemd generator reads the /etc/ld.conf and /etc/ld.conf.d/* to make the proper .path service
PathChanged=|/usr/lib PathChanged=|/usr/lib64
which will trigger the ldconfig
ExecStart=/sbin/ldconfig
Then, you can freely drop the ldconfig from %post scripts out.
Regards Michal Vyskocil
Still, library searching is costly and thus we require the ldconfig as an optimiziation.
Btw. if you want to see how libraries are searched run for example: LD_DEBUG=libs /bin/ls
Need help? LD_DEBUG=help /bin/ls
Andreas
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Tuesday, September 11, 2012 13:55:04 Michal Vyskocil wrote:
On Tue, Sep 11, 2012 at 09:31:21AM +0200, Andreas Jaeger wrote:
On Monday, September 10, 2012 18:38:57 Cristian Rodríguez wrote:
El 10/09/12 18:08, Dimstar / Dominique Leuenberger escribió:
You need to move the ldconfig call to the libhttrack2 sub package:
%post -n libhttrack2 -p /sbin/ldconfig %postun -n libhttrack2 -p /sbin/ldconfig
%post without -n <name> implies having the post on the main package; which in your case does not need it, as the lib lives in a sub - package.
Hth, Dominique
That being said, I wonder why we still need this in the first place, will it be possible to teach the linker to "keep an eye" on libraries already in the cache with inotify and rebuild it automagically when needed ?
You don't need it - the dynamic linker ld.so, e.g. on x86-64 it is /lib64/ld-linux-x86-64.so.2, will first check the cache and then check the filesystem.
Invoking ldconfig from ld.so would be really bad - and implementing ldconfig as a daemon is also not worth it.
Hallo,
you don't need to do so - all you need is to have proper systemd generator reads the /etc/ld.conf and /etc/ld.conf.d/* to make the proper .path service
PathChanged=|/usr/lib PathChanged=|/usr/lib64
which will trigger the ldconfig
ExecStart=/sbin/ldconfig
Then, you can freely drop the ldconfig from %post scripts out.
Cool!
Let's switch to systemd by default ;)
Is there a way to limit this so that it doesn't get run too often?
Andreas
On 11 September 2012 13:27, Andreas Jaeger aj@suse.com wrote:
On Tuesday, September 11, 2012 13:55:04 Michal Vyskocil wrote:
On Tue, Sep 11, 2012 at 09:31:21AM +0200, Andreas Jaeger wrote:
On Monday, September 10, 2012 18:38:57 Cristian Rodríguez wrote:
El 10/09/12 18:08, Dimstar / Dominique Leuenberger escribió:
You need to move the ldconfig call to the libhttrack2 sub package:
%post -n libhttrack2 -p /sbin/ldconfig %postun -n libhttrack2 -p /sbin/ldconfig
%post without -n <name> implies having the post on the main package; which in your case does not need it, as the lib lives in a sub - package.
Hth, Dominique
That being said, I wonder why we still need this in the first place, will it be possible to teach the linker to "keep an eye" on libraries already in the cache with inotify and rebuild it automagically when needed ?
You don't need it - the dynamic linker ld.so, e.g. on x86-64 it is /lib64/ld-linux-x86-64.so.2, will first check the cache and then check the filesystem.
Invoking ldconfig from ld.so would be really bad - and implementing ldconfig as a daemon is also not worth it.
Hallo,
you don't need to do so - all you need is to have proper systemd generator reads the /etc/ld.conf and /etc/ld.conf.d/* to make the proper .path service
PathChanged=|/usr/lib PathChanged=|/usr/lib64
which will trigger the ldconfig
ExecStart=/sbin/ldconfig
Then, you can freely drop the ldconfig from %post scripts out.
Cool!
Let's switch to systemd by default ;)
Is there a way to limit this so that it doesn't get run too often?
If that would be possible it would be the most similar thing to (not existing) rpm file triggers. It could be used for new MIME types, extraction of applications supported mime types from .desktop files and regeneration of GTK icon cache.
On Tue, Sep 11, 2012 at 02:27:18PM +0200, Andreas Jaeger wrote:
Cool!
Let's switch to systemd by default ;)
Is there a way to limit this so that it doesn't get run too often?
Uh, it makes no sense to move functionality that belongs into rpm into some other component. How about moving into page installation into systemd? We should make rpm run ldconfig automatically.
Cheers, Michael.
On 11 September 2012 13:58, Michael Schroeder mls@suse.de wrote:
We should make rpm run ldconfig automatically.
Sure. The problem is that we have been waiting for file triggers since at least http://stick.gk2.sk/2009/10/rpm-summit-at-the-opensuse-conference-2009/. Whatever the reason, from outside RPM development doesn't look very fast. But if someone volunteers... Or can we just use Mageia patch meanwhile? It's a ~400 lines patch...
On Tue, Sep 11, 2012 at 02:16:49PM +0100, Cristian Morales Vega wrote:
On 11 September 2012 13:58, Michael Schroeder mls@suse.de wrote:
We should make rpm run ldconfig automatically.
Sure. The problem is that we have been waiting for file triggers since at least http://stick.gk2.sk/2009/10/rpm-summit-at-the-opensuse-conference-2009/. Whatever the reason, from outside RPM development doesn't look very fast. But if someone volunteers... Or can we just use Mageia patch meanwhile? It's a ~400 lines patch...
It should be possible to do it with the new "collection" feature. (Too bad that I couldn't convince upstream to support virtual triggers ;( )
Cheers, Michael.
On 11 September 2012 14:18, Michael Schroeder mls@suse.de wrote:
On Tue, Sep 11, 2012 at 02:16:49PM +0100, Cristian Morales Vega wrote:
On 11 September 2012 13:58, Michael Schroeder mls@suse.de wrote:
We should make rpm run ldconfig automatically.
Sure. The problem is that we have been waiting for file triggers since at least http://stick.gk2.sk/2009/10/rpm-summit-at-the-opensuse-conference-2009/. Whatever the reason, from outside RPM development doesn't look very fast. But if someone volunteers... Or can we just use Mageia patch meanwhile? It's a ~400 lines patch...
It should be possible to do it with the new "collection" feature. (Too bad that I couldn't convince upstream to support virtual triggers ;( )
From 4.9.0 changelog: "EXPERIMENTAL support for package "collections"
which are sort of like named triggers that only run once within a transaction. This can be used for example to avoid redundant calls for cache updates etc. (XXX add link to documentation once it exists)"
I would be happier without that "EXPERIMENTAL" and "XXX add link to documentation once it exists". But if it can be done, absolutely!
On 11 September 2012 14:18, Michael Schroeder mls@suse.de wrote:
It should be possible to do it with the new "collection" feature. (Too bad that I couldn't convince upstream to support virtual triggers ;( )
From the description here:
http://www.mail-archive.com/rpm-maint@lists.rpm.org/msg01512.html Wouldn't using collections just move the requirement from a "%post -p /sbin/ldconfig" line to a "Collections: Library" line?
On Tue, Sep 11, 2012 at 02:38:26PM +0100, Cristian Morales Vega wrote:
On 11 September 2012 14:18, Michael Schroeder mls@suse.de wrote:
It should be possible to do it with the new "collection" feature. (Too bad that I couldn't convince upstream to support virtual triggers ;( )
From the description here:
http://www.mail-archive.com/rpm-maint@lists.rpm.org/msg01512.html Wouldn't using collections just move the requirement from a "%post -p /sbin/ldconfig" line to a "Collections: Library" line?
Dunno, I haven't looked at the details. If it can't be done, I'll try to push my virtual triggers upstream ;)
Cheers, Michael.
On 11 September 2012 16:59, Michael Schroeder mls@suse.de wrote:
Dunno, I haven't looked at the details. If it can't be done, I'll try to push my virtual triggers upstream ;)
The idea is to put a trigger in whatever package provides ldconfig and make find-provides automatically add this trigger target in every package that provides a library? No that I think Mageia's file triggers patch is elegant. But it seems more flexible than virtual triggers. If we ever have programs that update the caches atomically, how would virtual triggers pass the list of new libraries to ldconfig?
On Wed, Sep 12, 2012 at 11:58:24PM +0100, Cristian Morales Vega wrote:
On 11 September 2012 16:59, Michael Schroeder mls@suse.de wrote:
Dunno, I haven't looked at the details. If it can't be done, I'll try to push my virtual triggers upstream ;)
The idea is to put a trigger in whatever package provides ldconfig and make find-provides automatically add this trigger target in every package that provides a library?
Yes. Useful for lots of other stuff, too like adding/removing info pages, maybe creating users/groups etc.
No that I think Mageia's file triggers patch is elegant. But it seems more flexible than virtual triggers.
I think it's pretty similar, the difference is that virtual triggers are more "explicit", i.e. you can query which packages trigger ldconfig.
If we ever have programs that update the caches atomically, how would virtual triggers pass the list of new libraries to ldconfig?
Hmm, I don't get that. Why would you pass a list of libraries to ldconfig?
Cheers, Michael.
On 13 September 2012 10:04, Michael Schroeder mls@suse.de wrote:
If we ever have programs that update the caches atomically, how would virtual triggers pass the list of new libraries to ldconfig?
Hmm, I don't get that. Why would you pass a list of libraries to ldconfig?
Probably for ldconfig doesn't matter so much since it's quite fast. But there are other cache update programs that aren't so fast*, and the classic answer to that is: "pass the list of new entries to the program so it doesn't needs to regenerate the *full* cache each time".
* gtk-update-icon-cache takes 8 seconds on my machine to update the hicolor and oxygen themes caches. A program could install icons in even more themes...
On 11 September 2012 16:59, Michael Schroeder mls@suse.de wrote:
Dunno, I haven't looked at the details. If it can't be done, I'll try to push my virtual triggers upstream ;)
What's the status?
On Fri, Nov 16, 2012 at 02:26:54PM +0000, Cristian Morales Vega wrote:
On 11 September 2012 16:59, Michael Schroeder mls@suse.de wrote:
Dunno, I haven't looked at the details. If it can't be done, I'll try to push my virtual triggers upstream ;)
What's the status?
Too much other work right now. Maybe someone else has time to experiment with the "collection" feature?
Sorry, M.
On 16 November 2012 14:34, Michael Schroeder mls@suse.de wrote:
On Fri, Nov 16, 2012 at 02:26:54PM +0000, Cristian Morales Vega wrote:
On 11 September 2012 16:59, Michael Schroeder mls@suse.de wrote:
Dunno, I haven't looked at the details. If it can't be done, I'll try to push my virtual triggers upstream ;)
What's the status?
Too much other work right now. Maybe someone else has time to experiment with the "collection" feature?
OK. The collections stuff is like this:
- You add a "Collections: XXXXX" line to the preamble - rpmbuild stores XXXXX in the RPM. - When installed, rpm runs whatever %__collection_XXXXX (from /usr/lib/rpm/macros) is defined to in the user's machine.
The %__collection_XXXXX thing run a "plugin". Right now there are only two -- exec.so and sepolicy.so --, installed in /usr/lib64/rpm-plugins/. exec.so is a generic one that will run whatever is the parameter.
The plugin interface has six functions:
rpmRC PLUGINHOOK_INIT_FUNC(rpmts ts, const char * name, const char * opts); rpmRC PLUGINHOOK_CLEANUP_FUNC(void); rpmRC PLUGINHOOK_OPENTE_FUNC(rpmte te); rpmRC PLUGINHOOK_COLL_POST_ANY_FUNC(void); rpmRC PLUGINHOOK_COLL_POST_ADD_FUNC(void); rpmRC PLUGINHOOK_COLL_PRE_REMOVE_FUNC(void);
The exec.so plugin only runs in PLUGINHOOK_COLL_POST_ANY_FUNC; Having access to rpmte I guess you can do all kind of funny things. But in general we should have enough with exec.so.
Conclusion: until the libzypp guys start to run more than a single RPM in each transaction we are not winning a lot here. There is not a big difference between adding a "%reconfigure_fonts_scriptlets" line to your .spec file as we do now, or a "Collections: font" line. But once the libzypp guys start using bigger transaction this will make them faster.
In any case this doesn't solve the "we want to add a new scriptlet and it takes 5 years for all packages to be adapted" problem (gtk-update-icon-cache for all the packages with icons). We need one of:
- Mandrivas's file triggers patch - Virtual triggers - find-collections so all packages with files under /usr/share/fonts/ would be automatically added to the "font" collections (and change %__collection_font to use fonts-config instead of fc-cache directly ;-) )
Possible for 12.3 + 1?
On Tue, Feb 19, 2013 at 04:18:26PM +0000, Cristian Morales Vega wrote:
- Mandrivas's file triggers patch
- Virtual triggers
- find-collections so all packages with files under /usr/share/fonts/
would be automatically added to the "font" collections (and change %__collection_font to use fonts-config instead of fc-cache directly ;-) )
I'm at the Fedora DevCon this weekend meeting with the RedHat RPM guys. We'll talk about how to proceed with automatic ldconfig calling and other improvements.
Cheers, Michael.
El 19/02/13 14:05, Michael Schroeder escribió:
On Tue, Feb 19, 2013 at 04:18:26PM +0000, Cristian Morales Vega wrote:
- Mandrivas's file triggers patch
- Virtual triggers
- find-collections so all packages with files under /usr/share/fonts/
would be automatically added to the "font" collections (and change %__collection_font to use fonts-config instead of fc-cache directly ;-) )
I'm at the Fedora DevCon this weekend meeting with the RedHat RPM guys. We'll talk about how to proceed with automatic ldconfig calling and other improvements.
Cheers, Michael.
Thank you for taking the time for looking into this, it is long overdue :-)
On 19 February 2013 17:05, Michael Schroeder mls@suse.de wrote:
On Tue, Feb 19, 2013 at 04:18:26PM +0000, Cristian Morales Vega wrote:
- Mandrivas's file triggers patch
- Virtual triggers
- find-collections so all packages with files under /usr/share/fonts/
would be automatically added to the "font" collections (and change %__collection_font to use fonts-config instead of fc-cache directly ;-) )
I'm at the Fedora DevCon this weekend meeting with the RedHat RPM guys. We'll talk about how to proceed with automatic ldconfig calling and other improvements.
There is any blog/mailing list explaining what was decided there?
On Tue, Mar 19, 2013 at 09:15:59PM +0000, Cristian Morales Vega wrote:
On 19 February 2013 17:05, Michael Schroeder mls@suse.de wrote:
On Tue, Feb 19, 2013 at 04:18:26PM +0000, Cristian Morales Vega wrote:
- Mandrivas's file triggers patch
- Virtual triggers
- find-collections so all packages with files under /usr/share/fonts/
would be automatically added to the "font" collections (and change %__collection_font to use fonts-config instead of fc-cache directly ;-) )
I'm at the Fedora DevCon this weekend meeting with the RedHat RPM guys. We'll talk about how to proceed with automatic ldconfig calling and other improvements.
There is any blog/mailing list explaining what was decided there?
Oh, sorry, I forgot to followup to my mail.
I talked with Panu about the current state and how to proceed. We agreed that I implement the virtual triggers support and send a patch to the rpm-maint mailing list. The collection mechanism seems to be not in a usable state right now.
Cheers, Michael.
On Wed, Mar 20, 2013 at 3:13 PM, Michael Schroeder mls@suse.de wrote:
On Tue, Mar 19, 2013 at 09:15:59PM +0000, Cristian Morales Vega wrote:
On 19 February 2013 17:05, Michael Schroeder mls@suse.de wrote:
On Tue, Feb 19, 2013 at 04:18:26PM +0000, Cristian Morales Vega wrote:
- Mandrivas's file triggers patch
- Virtual triggers
- find-collections so all packages with files under /usr/share/fonts/
would be automatically added to the "font" collections (and change %__collection_font to use fonts-config instead of fc-cache directly ;-) )
I'm at the Fedora DevCon this weekend meeting with the RedHat RPM guys. We'll talk about how to proceed with automatic ldconfig calling and other improvements.
There is any blog/mailing list explaining what was decided there?
Oh, sorry, I forgot to followup to my mail.
I talked with Panu about the current state and how to proceed. We agreed that I implement the virtual triggers support and send a patch to the rpm-maint mailing list. The collection mechanism seems to be not in a usable state right now.
Not willing to open can of worms, but is migration to RPM5 out of discussion?
On Wed, Mar 20, 2013 at 04:58:11PM +0400, Andrey Borzenkov wrote:
Not willing to open can of worms, but is migration to RPM5 out of discussion?
Well, for me sticking with RPM4 is basically done because of a const-benefit analysis. Switching to RPM5 is hard work (see the pain Mandriva had), and I don't see many things that we need that are in RPM5 and are missing from RPM4.
Most of my time is spent developing for the open build service, the little time that is left for rpm is barely enough for doing some small hacks and updating to the latest minor version.
Cheers, Michael.
On Tue, Sep 11, 2012 at 02:58:59PM +0200, Michael Schroeder wrote:
On Tue, Sep 11, 2012 at 02:27:18PM +0200, Andreas Jaeger wrote:
Cool!
Let's switch to systemd by default ;)
Is there a way to limit this so that it doesn't get run too often?
Uh, it makes no sense to move functionality that belongs into rpm into some other component. How about moving into page installation into systemd?
Do not say it too loud, or next year systemd can on-demand install RPMs as PackageKit & rpm replacement.
Ciao, Marcius
On Tuesday 11 September 2012, Marcus Meissner wrote:
On Tue, Sep 11, 2012 at 02:58:59PM +0200, Michael Schroeder wrote:
On Tue, Sep 11, 2012 at 02:27:18PM +0200, Andreas Jaeger wrote:
Cool!
Let's switch to systemd by default ;)
Is there a way to limit this so that it doesn't get run too often?
Uh, it makes no sense to move functionality that belongs into rpm into some other component. How about moving into page installation into systemd?
Do not say it too loud, or next year systemd can on-demand install RPMs as PackageKit & rpm replacement.
Don't worry, more likely systemd will implement any other functionality so that you simply don't need to install any other packages anymore.
cu, Rudi
On Tue, Sep 11, 2012 at 02:58:59PM +0200, Michael Schroeder wrote:
On Tue, Sep 11, 2012 at 02:27:18PM +0200, Andreas Jaeger wrote:
Cool!
Let's switch to systemd by default ;)
Is there a way to limit this so that it doesn't get run too often?
Uh, it makes no sense to move functionality that belongs into rpm into some other component. How about moving into page installation into systemd?
At least it will solve things installed without rpm - however the question is how much sane is to support that ...
We should make rpm run ldconfig automatically.
Definitelly!
Regards Michal Vyskocil
Michal Vyskocil wrote:
[...] you don't need to do so - all you need is to have proper systemd generator reads the /etc/ld.conf and /etc/ld.conf.d/* to make the proper .path service
PathChanged=|/usr/lib PathChanged=|/usr/lib64
which will trigger the ldconfig
ExecStart=/sbin/ldconfig
Then, you can freely drop the ldconfig from %post scripts out.
Unless you install a chroot... The proper solution would be IMO a) allow ldconfig to (un-)register individual libraries directly so it doesn't have to scan all directories all the time b) make rpm call ldconfig on individual libraries automatically
cu Ludwig
On Tue, Sep 11, 2012 at 02:43:12PM +0200, Ludwig Nussel wrote:
Michal Vyskocil wrote:
[...] you don't need to do so - all you need is to have proper systemd generator reads the /etc/ld.conf and /etc/ld.conf.d/* to make the proper .path service
PathChanged=|/usr/lib PathChanged=|/usr/lib64
which will trigger the ldconfig
ExecStart=/sbin/ldconfig
Then, you can freely drop the ldconfig from %post scripts out.
Unless you install a chroot... The proper solution would be IMO a) allow ldconfig to (un-)register individual libraries directly so it doesn't have to scan all directories all the time b) make rpm call ldconfig on individual libraries automatically
Well, then lets deprecate chroot in favor of systemd-nspawn ;-)
But seriously - I am not pretty sure if systemd will handle that correctly, but what will happen if we will have the ldconfig-generator and ldconfig.service pulled in as dependencies, will the PID 1 act or not?
If not, then unfortunatelly we have the counter-example of the systemd-way ...
Regards Michal Vyskocil
On Tue, Sep 11, 2012 at 02:43:12PM +0200, Ludwig Nussel wrote:
Michal Vyskocil wrote:
[...] you don't need to do so - all you need is to have proper systemd generator reads the /etc/ld.conf and /etc/ld.conf.d/* to make the proper .path service
PathChanged=|/usr/lib PathChanged=|/usr/lib64
which will trigger the ldconfig
ExecStart=/sbin/ldconfig
Then, you can freely drop the ldconfig from %post scripts out.
Unless you install a chroot... The proper solution would be IMO a) allow ldconfig to (un-)register individual libraries directly so it doesn't have to scan all directories all the time b) make rpm call ldconfig on individual libraries automatically
Reading the ldconfig manual page - isn't the -l
-l Library mode. Manually link individual libraries. Intended for use by experts only.
supposed to do that?
Regards Michal Vyskocil
On Tuesday, September 11, 2012 15:21:45 Michal Vyskocil wrote:
On Tue, Sep 11, 2012 at 02:43:12PM +0200, Ludwig Nussel wrote:
Michal Vyskocil wrote:
[...] you don't need to do so - all you need is to have proper systemd generator reads the /etc/ld.conf and /etc/ld.conf.d/* to make the proper .path service
PathChanged=|/usr/lib PathChanged=|/usr/lib64
which will trigger the ldconfig
ExecStart=/sbin/ldconfig
Then, you can freely drop the ldconfig from %post scripts out.
Unless you install a chroot... The proper solution would be IMO a) allow ldconfig to (un-)register individual libraries directly so it> doesn't have to scan all directories all the time
b) make rpm call ldconfig on individual libraries automatically
Reading the ldconfig manual page - isn't the -l
-l Library mode. Manually link individual libraries. Intended for use by experts only.
supposed to do that?
-l does not change the cache, just creates links,
Andreas
Le mardi 11 septembre 2012 à 13:55 +0200, Michal Vyskocil a écrit :
On Tue, Sep 11, 2012 at 09:31:21AM +0200, Andreas Jaeger wrote:
On Monday, September 10, 2012 18:38:57 Cristian Rodríguez wrote:
El 10/09/12 18:08, Dimstar / Dominique Leuenberger escribió:
You need to move the ldconfig call to the libhttrack2 sub package:
%post -n libhttrack2 -p /sbin/ldconfig %postun -n libhttrack2 -p /sbin/ldconfig
%post without -n <name> implies having the post on the main package; which in your case does not need it, as the lib lives in a sub - package.
Hth, Dominique
That being said, I wonder why we still need this in the first place, will it be possible to teach the linker to "keep an eye" on libraries already in the cache with inotify and rebuild it automagically when needed ?
You don't need it - the dynamic linker ld.so, e.g. on x86-64 it is /lib64/ld-linux-x86-64.so.2, will first check the cache and then check the filesystem.
Invoking ldconfig from ld.so would be really bad - and implementing ldconfig as a daemon is also not worth it.
Hallo,
you don't need to do so - all you need is to have proper systemd generator reads the /etc/ld.conf and /etc/ld.conf.d/* to make the proper .path service
PathChanged=|/usr/lib PathChanged=|/usr/lib64
which will trigger the ldconfig
ExecStart=/sbin/ldconfig
Then, you can freely drop the ldconfig from %post scripts out.
It would be better to have support in rpm for file triggers (we had a patch for that in Mandriva RPM since 2008 and I think it is slowly coming to upstream RPM, under the name "collection"). cf http://www.mail-archive.com/rpm-maint@lists.rpm.org/msg01534.html
On Mon, Sep 10, 2012 at 5:08 PM, Dimstar / Dominique Leuenberger dimstar@opensuse.org wrote:
On Mon, 2012-09-10 at 17:05 -0400, Greg Freemyer wrote:
All,
I sent the httrack package to security a couple weeks ago. It builds, but with a few rpmlint issues.
I thought I would clean up the one about the shared library needing to be split out to its own package.
I've tried to do that in home:gregfreemyer:branches:security > httrack
The diff is: https://build.opensuse.org/package/rdiff?opackage=httrack&oproject=secur...
I've tried multiple ways to call ldconfig.
But my build always fails with:
[ 218s] libhttrack2.x86_64: E: library-without-ldconfig-postin (Badness: 300) /usr/lib64/libhtsjava.so.2.0.46 [ 218s] libhttrack2.x86_64: E: library-without-ldconfig-postin (Badness: 300) /usr/lib64/libhttrack.so.2.0.46 [ 218s] This package contains a library and provides no %post scriptlet containing a [ 218s] call to ldconfig.
You need to move the ldconfig call to the libhttrack2 sub package:
%post -n libhttrack2 -p /sbin/ldconfig %postun -n libhttrack2 -p /sbin/ldconfig
%post without -n <name> implies having the post on the main package; which in your case does not need it, as the lib lives in a sub - package.
Hth, Dominique
Thanks
I updated one of the examples at: http://en.opensuse.org/openSUSE:Packaging_scriptlet_snippets#Shared_librarie...
to have a sub-package.
Greg
-
Andreas Jaeger -
Andrey Borzenkov -
Cristian Morales Vega -
Cristian Rodríguez -
Dimstar / Dominique Leuenberger -
Frederic Crozat -
Greg Freemyer -
Ludwig Nussel -
Marcus Meissner -
Michael Schroeder -
Michal Vyskocil -
Ruediger Meier