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=security&package=httrack&project=home%3Agregfreemyer%3Abranches%3Asecurity&rev=2

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 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Mon, Sep 10, 2012 at 5:08 PM, Dimstar / Dominique Leuenberger 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=security&package=httrack&project=home%3Agregfreemyer%3Abranches%3Asecurity&rev=2

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 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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 11 September 2012 13:27, Andreas Jaeger 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. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 11 September 2012 13:58, Michael Schroeder 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... -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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

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 -- 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 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 -- 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 11 September 2012 16:59, Michael Schroeder 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? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 13 September 2012 10:04, Michael Schroeder 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... -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 11 September 2012 16:59, Michael Schroeder 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? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 16 November 2012 14:34, Michael Schroeder wrote:

On Fri, Nov 16, 2012 at 02:26:54PM +0000, Cristian Morales Vega wrote:

...

On 11 September 2012 16:59, Michael Schroeder 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? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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 :-) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tue, Mar 19, 2013 at 09:15:59PM +0000, Cristian Morales Vega wrote:

On 19 February 2013 17:05, Michael Schroeder 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. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org