On Mon, Oct 27, 2008 at 6:19 PM, Jeff Johnson <email@example.com> wrote:
> If you eyeball
> rpm -qa --scripts
> spewage, one of the, if not _THE_, most common scriptlets in rpm packages
> on linux is this:
> %post -p /sbin/ldconfig
> One does not have to look too hard to find discussion about
> how slow rpm is (ldconfig can be slow, rpm bottlenecks cannot be fixed
> by fiddling with ldconfig), and how stoopidly unnecessary it is to run
> ldconfig twice for every package upgrade (running twice is stoopid,
> so why is running /sbin/ldconfig perhaps __THE__ commonest package
> Or if you're too lazy to search for previous discussions
> about how ldconfig could/should be done in *.rpm packages, wait
> a bit, there's a Newer! Better! Bestest! proposal every
> 6 months or so.
> There's very little that ldconfig actually needs to do. Quoting
> from "man ldconfig" 1st paragraph, here is a paraphrase of what functions
> ldconfig performs:
> 1) create a (mostly legacy) symlink that points to a package
> that contains a DT_SONAME.
> 2) register the DT_SONAME entry in /etc/ld.so.cache
> and that's basically all that /sbin/ldconfig does.
> Neither of the above operations is very hard to program, in C,
> or (as I am proposing) using a lua script.
> I suggest that a lua script could & should do those tasks
> internal to rpm, thereby removing the need for every
> package that contains a DSO library from having to perform
> their own speshully crafted variants of what are intrinsically
> very simple operations by invoking /sbin/ldconfig.
> All the information, including path to library, the DT_SONAME contained
> within the library, are already present in rpm package metadata for
> almost a decade. Is there any additional benefit to continue invoking
> /sbin/ldconfig also?
> There is one reason that I am aware of, the format used internally
> to /etc/ld.so is "private" to glibc, and, in principle, might
> change for any reason that glibc decides.
> Note that in practice, the format __MIGHT__ change like once
> a decade or so. A handful of formats could be easily accomodated,
> I'm quite sure that any/all changes to the data structures
> contained in /etc/ld.so are reliably detected
> Is there any reason __NOT__ to attempt doing what /sbin/ldconfig
> does within rpm to improve package upgrade perfomance?
> (CC: to drepper, I'm sure he will have something to say. FWIW
> I discussed the issue with him at OLS 2006 and there may be other
> means to continue hiding the data structure while permitting
> alternative means of doing what /sbin/ldconfig does).
Could be a very nice way to speedup the rpm installation/update procedure.
But i think it should be
done in a portable way (e.g. different OS use often different implementation
for doing what ldconfig do on linux
and different libc have different requisite - dietlibc UClibc and so on).
But are you sure that could be a positive thing
for RPM to know internally all this - low level - OS difference ? Exists a
tradeoff here IMHO.
- rpm performance in general
- for better spec portability : if
> 73 de Jeff
> RPM Package Manager http://rpm5.org
> Developer Communication List firstname.lastname@example.org
Received on Tue Oct 28 10:58:02 2008