[RFC] change packaging around shared libraries, ldconfig

[Bill Nottingham]

Sent here before -packaging as I'd like comments before finalizing
the draft.

....

I'd like to propose changing the guidelines regarding shared libraries
as follows:

When a package places a shared library in a standard library path, it
must do the following:

- Package the symlinks for the appropriate soname of the library. If
  the normal installation process of the library does not install these
  symlinks, they can be created by running:
  	/sbin/ldconfig -n -N <path>
- Have the following scriplets in the package:

	%posttrans -p /sbin/ldconfig

Rationale:

ldconfig can be very slow. On a test upgrade of Fedora 7 to the current
updates and updates-testing repository, not running ldconfig on
%post/%postun sped up the upgrade process by 33%. [1] If these symlinks
are properly packaged, there is no need to explicitly call ldconfig.
Calling ldconfig once at the end of the transaction should be enough
to guarantee any necessary cleanup is done.

Bill

[1] https://lists.dulug.duke.edu/pipermail/rpm-maint/2007-June/000407.html

[Rex Dieter]

Bill Nottingham wrote:

>  I'd like to propose changing the guidelines regarding shared
> libraries
>  as follows:
>  
>  When a package places a shared library in a standard library path, it
>  must do the following:
>  
>  - Package the symlinks for the appropriate soname of the library. If
>    the normal installation process of the library does not install these
>    symlinks, they can be created by running:
>    /sbin/ldconfig -n -N <path>
>  - Have the following scriplets in the package:
>  
>  %posttrans -p /sbin/ldconfig 
Doesn't ldconfig also update ld.so.cache?  If so, won't "bad things"
happen
if that cache is stale, like when/if 2 pkgs are installed in a transaction,
and pkg #2 depends on shlibs from pkg #1?

-- Rex

[Bill Nottingham]

Rex Dieter (rdieter(a)math.unl.edu) said: 
>  Doesn't ldconfig also update ld.so.cache?  If so, won't
> "bad things" happen
>  if that cache is stale, like when/if 2 pkgs are installed in a transaction,
>  and pkg #2 depends on shlibs from pkg #1? 
If the cache is stale, it will look in the directories for something that
doesn't exist in the cache. I'm trying to think of a way the cache could
point to the wrong *version* of the library, but nothing is coming to
mind.

Bill

[Rex Dieter]

Bill Nottingham wrote:

>  Rex Dieter (rdieter(a)math.unl.edu) said:
> > Doesn't ldconfig also update ld.so.cache?  If so, won't "bad
> things"
> > happen if that cache is stale, like when/if 2 pkgs are installed in a
> > transaction, and pkg #2 depends on shlibs from pkg #1?
>  
>  If the cache is stale, it will look in the directories for something that
>  doesn't exist in the cache. I'm trying to think of a way the cache could
>  point to the wrong *version* of the library, but nothing is coming to
>  mind. 
pkg #1 upgrade: old version includes libfoo.so.1, new version includes
libfoo.so.2
pkg #2: scriptlet requires something from pkg #1, which uses libfoo.so.2
bang.

??

-- Rex

[seth vidal]

On Wed, 2007-06-27 at 09:36 -0500, Rex Dieter wrote:
>  Bill Nottingham wrote:
>  
>  > Rex Dieter (rdieter(a)math.unl.edu) said:
>  >> Doesn't ldconfig also update ld.so.cache?  If so, won't "bad
> things"
>  >> happen if that cache is stale, like when/if 2 pkgs are installed in a
>  >> transaction, and pkg #2 depends on shlibs from pkg #1?
>  > 
>  > If the cache is stale, it will look in the directories for something that
>  > doesn't exist in the cache. I'm trying to think of a way the cache could
>  > point to the wrong *version* of the library, but nothing is coming to
>  > mind.
>  
>  pkg #1 upgrade: old version includes libfoo.so.1, new version includes
>  libfoo.so.2
>  pkg #2: scriptlet requires something from pkg #1, which uses libfoo.so.2
>  bang. 
how would that break?

an update is an install then an erase.

so we install libfoo which drops in libfoo.so.2 and the symlinks it
needs

If the scriptlets have a special preun req then they need to have it
listed.

-sv

[Jakub Jelinek]

On Wed, Jun 27, 2007 at 09:36:04AM -0500, Rex Dieter wrote:
>  > Rex Dieter (rdieter(a)math.unl.edu) said:
>  >> Doesn't ldconfig also update ld.so.cache?  If so, won't "bad
> things"
>  >> happen if that cache is stale, like when/if 2 pkgs are installed in a
>  >> transaction, and pkg #2 depends on shlibs from pkg #1?
>  > 
>  > If the cache is stale, it will look in the directories for something that
>  > doesn't exist in the cache. I'm trying to think of a way the cache could
>  > point to the wrong *version* of the library, but nothing is coming to
>  > mind.
>  
>  pkg #1 upgrade: old version includes libfoo.so.1, new version includes
>  libfoo.so.2
>  pkg #2: scriptlet requires something from pkg #1, which uses libfoo.so.2
>  bang. 
Only if libfoo.so.2 is in some non-standard path.  If it is in
{,/usr}/lib{,64}, then when it won't be found in ld.so.cache, it will be
searched in the standard paths.

	Jakub

[Jef Spaleta]

On 6/27/07, Bill Nottingham <notting(a)redhat.com&gt; wrote:
>  If the cache is stale, it will look in the directories for something
> that
>  doesn't exist in the cache. I'm trying to think of a way the cache could
>  point to the wrong *version* of the library, but nothing is coming to
>  mind. 
Pathological case?
Forcing the install of a duplicate library package when there is a
soname version bump and there isn't a compat package and you want to
keep the old library version on your local system?

-jef"i'd rather be fishing"spaleta

[Bill Nottingham]

Jeff Spaleta (jspaleta(a)gmail.com) said: 
> > If the cache is stale, it will look in the directories for
> something that
> > doesn't exist in the cache. I'm trying to think of a way the cache could
> > point to the wrong *version* of the library, but nothing is coming to
> > mind.
>
>  Pathological case?
>  Forcing the install of a duplicate library package when there is a
>  soname version bump and there isn't a compat package and you want to
>  keep the old library version on your local system? 
Then the soname doesn't match, so it will DTRT anyway. If the soname
is the same, you'll only have the new library on the system, so the
cache can't be 'stale' there either in a way that gives you the wrong
library.

Bill

[Jakub Jelinek]

On Wed, Jun 27, 2007 at 10:42:31AM -0400, Bill Nottingham wrote:
>  Jeff Spaleta (jspaleta(a)gmail.com) said: 
>  >> If the cache is stale, it will look in the directories for something that
>  >> doesn't exist in the cache. I'm trying to think of a way the cache
> could
>  >> point to the wrong *version* of the library, but nothing is coming to
>  >> mind.
>  >
>  > Pathological case?
>  > Forcing the install of a duplicate library package when there is a
>  > soname version bump and there isn't a compat package and you want to
>  > keep the old library version on your local system?
>  
>  Then the soname doesn't match, so it will DTRT anyway. If the soname
>  is the same, you'll only have the new library on the system, so the
>  cache can't be 'stale' there either in a way that gives you the wrong
>  library. 
Well, if you are moving the same SONAME to a different path (found earlier
in ldconfig's search path) and adding new symbols at the same time, you can
have issues.
Say, package foobar used to have libfoobar.so.1 in /usr/lib64, a new
version moves it to /lib64 because barbaz program needs it before /usr is
mounted.  If it adds a new symbol foo to that library at the same time
and /bin/bar program which is run during %post needs it, you loose
without ldconfig run.

	Jakub

[Bill Nottingham]

Jakub Jelinek (jakub(a)redhat.com) said: 
>  Well, if you are moving the same SONAME to a different path (found
> earlier
>  in ldconfig's search path) and adding new symbols at the same time, you can
>  have issues.
>  Say, package foobar used to have libfoobar.so.1 in /usr/lib64, a new
>  version moves it to /lib64 because barbaz program needs it before /usr is
>  mounted.  If it adds a new symbol foo to that library at the same time
>  and /bin/bar program which is run during %post needs it, you loose
>  without ldconfig run. 
This is the only case, though - correct? So this case could be handled
with a trigger, or something similar.

Bill

[Matthias Saou]

Bill Nottingham wrote :

>  Sent here before -packaging as I'd like comments before
> finalizing
>  the draft. 
My hero! :-)

I'm always all for ripping out any useless stuff, so if all of those
ldconfig calls can simply be avoided, count me in for the spec
file patching fest ;-)

Matthias

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora release 7 (Moonshine) - Linux kernel 2.6.21-1.3228.fc7
Load : 0.19 0.32 0.34

[Jan Kratochvil]

On Wed, 27 Jun 2007 15:43:13 +0200, Bill Nottingham wrote:
>  Sent here before -packaging as I'd like comments before
> finalizing
>  the draft.
>  
>  ....
>  
>  I'd like to propose changing the guidelines regarding shared libraries
>  as follows: 
...
>  ldconfig can be very slow. 
FYI there is now being discussed an incremental ldconfig patch upstream:
	http://sourceware.org/ml/libc-alpha/2007-06/msg00118.html


Jan

[Bill Nottingham]

Jan Kratochvil (jan.kratochvil(a)redhat.com) said: 
>  FYI there is now being discussed an incremental ldconfig patch
> upstream:
>  	http://sourceware.org/ml/libc-alpha/2007-06/msg00118.html 
Sure. It's still slower than not running it at all. 

Bill