10 Sep
2012
10 Sep
'12
22:05
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=secu…
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
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
10 Sep
10 Sep
22:08
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=secu…
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(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
22:38
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 ?
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
11 Sep
11 Sep
08:31
On Monday, September 10, 2012 18:38:57 Cristian Rodríguez wrote:
El 10/09/12 18:08, Dimstar / Dominique Leuenberger
escribió:
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
--
Andreas Jaeger aj(a){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(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
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 ? 
12:55
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:
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
El 10/09/12 18:08, Dimstar / Dominique
Leuenberger escribió:
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. 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 ?
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(a){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(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
13:27
On Tuesday, September 11, 2012 13:55:04 Michal Vyskocil wrote:
On Tue, Sep 11, 2012 at 09:31:21AM +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?
Andreas
--
Andreas Jaeger aj(a){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(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
On Monday, September 10, 2012 18:38:57 Cristian
Rodríguez wrote:
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. El 10/09/12 18:08, Dimstar / Dominique
Leuenberger escribió:
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. 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 ? 
13:41
On 11 September 2012 13:27, Andreas Jaeger <aj(a)suse.com> wrote:
On Tuesday, September 11, 2012 13:55:04 Michal
Vyskocil wrote:
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(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
On Tue, Sep 11, 2012 at 09:31:21AM +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? On Monday, September 10, 2012 18:38:57 Cristian
Rodríguez wrote:
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. 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. 
13:58
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(a)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(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
14:16
On 11 September 2012 13:58, Michael Schroeder <mls(a)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...
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
14:18
On Tue, Sep 11, 2012 at 02:16:49PM +0100, Cristian Morales Vega wrote:
On 11 September 2012 13:58, Michael Schroeder
<mls(a)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 ;( )
Cheers,
Michael.
--
Michael Schroeder mls(a)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(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
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...
14:28
On 11 September 2012 14:18, Michael Schroeder <mls(a)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(a)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 ;( ) 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... 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!
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
14:38
On 11 September 2012 14:18, Michael Schroeder <mls(a)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?
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
16:59
On Tue, Sep 11, 2012 at 02:38:26PM +0100, Cristian Morales Vega wrote:
On 11 September 2012 14:18, Michael Schroeder
<mls(a)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 ;)
Cheers,
Michael.
--
Michael Schroeder mls(a)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(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
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?
12 Sep
12 Sep
23:58
On 11 September 2012 16:59, Michael Schroeder <mls(a)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?
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
13 Sep
13 Sep
10:04
On Wed, Sep 12, 2012 at 11:58:24PM +0100, Cristian Morales Vega wrote:
On 11 September 2012 16:59, Michael Schroeder
<mls(a)suse.de> wrote:
Yes. Useful for lots of other stuff, too like adding/removing info
pages, maybe creating users/groups etc.
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.
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.
--
Michael Schroeder mls(a)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(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
10:25
On 13 September 2012 10:04, Michael Schroeder <mls(a)suse.de> wrote:
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(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
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?
16 Nov
16 Nov
14:26
On 11 September 2012 16:59, Michael Schroeder <mls(a)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?
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
14:34
On Fri, Nov 16, 2012 at 02:26:54PM +0000, Cristian Morales Vega wrote:
On 11 September 2012 16:59, Michael Schroeder
<mls(a)suse.de> wrote:
Too much other work right now. Maybe someone else has time to
experiment with the "collection" feature?
Sorry,
M.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
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?
19 Feb
19 Feb
16:18
On 16 November 2012 14:34, Michael Schroeder <mls(a)suse.de> wrote:
On Fri, Nov 16, 2012 at 02:26:54PM +0000, Cristian
Morales Vega wrote:
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(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
On 11 September 2012 16:59, Michael Schroeder
<mls(a)suse.de> wrote:
Too much other work right now. Maybe someone else has time to
experiment with the "collection" feature? 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?
17:05
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.
--
Michael Schroeder mls(a)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(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
17:18
El 19/02/13 14:05, Michael Schroeder escribió:
On Tue, Feb 19, 2013 at 04:18:26PM +0000, Cristian
Morales Vega wrote:
Thank you for taking the time for looking into this, it is long overdue :-)
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
- 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.
19 Mar
19 Mar
21:15
On 19 February 2013 17:05, Michael Schroeder <mls(a)suse.de> wrote:
On Tue, Feb 19, 2013 at 04:18:26PM +0000, Cristian
Morales Vega wrote:
There is any blog/mailing list explaining what was decided there?
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
- 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.
20 Mar
20 Mar
11:13
On Tue, Mar 19, 2013 at 09:15:59PM +0000, Cristian Morales Vega wrote:
On 19 February 2013 17:05, Michael Schroeder
<mls(a)suse.de> wrote:
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(a)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(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
On Tue, Feb 19, 2013 at 04:18:26PM +0000,
Cristian Morales Vega wrote:
There is any blog/mailing list explaining what was decided there? - 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. 
12:58
On Wed, Mar 20, 2013 at 3:13 PM, Michael Schroeder <mls(a)suse.de> wrote:
On Tue, Mar 19, 2013 at 09:15:59PM +0000, Cristian
Morales Vega wrote:
Not willing to open can of worms, but is migration to RPM5 out of discussion?
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
On 19 February 2013 17:05, Michael Schroeder
<mls(a)suse.de> wrote:
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.
On Tue, Feb 19, 2013 at 04:18:26PM +0000,
Cristian Morales Vega wrote:
There is any blog/mailing list explaining what was decided there? - 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.
13:40
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(a)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(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
11 Sep
11 Sep
14:20
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:
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(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
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? 
14:33
On Tuesday 11 September 2012, Marcus Meissner wrote:
On Tue, Sep 11, 2012 at 02:58:59PM +0200, Michael
Schroeder wrote:
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(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
On Tue, Sep 11, 2012 at 02:27:18PM +0200, Andreas
Jaeger wrote:
Do not say it too loud, or next year systemd can on-demand install
RPMs as PackageKit & rpm replacement. 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?
14:24
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:
At least it will solve things installed without rpm - however the
question is how much sane is to support that ...
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.
Definitelly!
Regards
Michal Vyskocil
13:43
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
--
(o_ Ludwig Nussel
//\
V_/_ http://www.suse.de/
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG
Nürnberg)
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
14:04
On Tue, Sep 11, 2012 at 02:43:12PM +0200, Ludwig Nussel wrote:
Michal Vyskocil wrote:
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
[...]
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
14:21
On Tue, Sep 11, 2012 at 02:43:12PM +0200, Ludwig Nussel wrote:
Michal Vyskocil wrote:
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
[...]
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
14:39
On Tuesday, September 11, 2012 15:21:45 Michal Vyskocil wrote:
On Tue, Sep 11, 2012 at 02:43:12PM +0200, Ludwig
Nussel wrote:
-l does not change the cache, just creates links,
Andreas
--
Andreas Jaeger aj(a){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(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Michal Vyskocil wrote:
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? [...]
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 
17 Sep
17 Sep
13:55
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:
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
--
Frederic Crozat <fcrozat(a)suse.com>
SUSE
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
On Monday, September 10, 2012 18:38:57 Cristian
Rodríguez wrote:
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. El 10/09/12 18:08, Dimstar / Dominique
Leuenberger escribió:
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. 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 ?
10 Sep
10 Sep
23:46
On Mon, Sep 10, 2012 at 5:08 PM, Dimstar / Dominique Leuenberger
<dimstar(a)opensuse.org> wrote:
On Mon, 2012-09-10 at 17:05 -0400, Greg Freemyer wrote:
Thanks
I updated one of the examples at:
http://en.opensuse.org/openSUSE:Packaging_scriptlet_snippets#Shared_librari…
to have a sub-package.
Greg
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
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=secu…
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
3113
days inactive
3304
days old
33 comments
12 participants
participants (12)
-
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