[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#447609: ldconfig triggerisation



Daniel Jacobowitz writes ("Re: Bug#447609: ldconfig triggerisation"):
> On Mon, Oct 22, 2007 at 04:07:05PM +0100, Ian Jackson wrote:
> > [assumptions]
> 
> Note that this is usually true but not always; it may be true
> enough for our purposes but I want to set the record straight.

Thanks.

> The only failure case I can think of would be a package which places
> libraries in the multi-arch directories, which Debian locates using a
> file in /etc/ld.so.conf.d, and the same or another package which runs
> a newly installed program using the library from the first package
> in its postinst.

Do such packages typically invoke ldconfig in the same way as a normal
package does ?  If not then we could distinguish the two kinds of
ldconfig call.

> If usage of those directories is planned to increase this may become
> a problem.

Yes, I see.

Joey Hess writes ("Re: Bug#447609: ldconfig triggerisation"):
> Couldn't file triggers be used, so ldconfig is triggered after any
> package installs a library file? That's much more how I expected
> triggers to be used, rather than needing an ugly ldconfig wrapper. I
> think it also addresses drow's point about libraries in nonstandard
> locations, since those packages could just run ldconfig as usual.
> Meanwhile, packages installing libraries to standard locations could
> stop calling ldconfig.

Unfortunately because of the way /lib and particularly /usr/lib are
dumping grounds, file triggers wouldn't work properly.  A file trigger
is activated by packages' files whose pathnames start with the name of
the trigger.  So the trigger would have to be /usr/lib/ but that
covers enormous amounts of junk.

Also, doing it like that would mean we should probably wait with
starting on those changes to packages until the dpkg (and apt and
aptitude) with triggers were actually deployed, as otherwise in the
meantime ldconfig wouldn't run at all.

Ian.




Reply to: