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

Re: [olpc-software] Package manager stuff



On Wed, 2006-03-15 at 14:22 -0500, David Zeuthen wrote:
> Btw, I was wondering whether we really need union mounts to make your
> proposal work? Won't playing tricks with PATH and LD_LIBRARY_PATH work
> instead? If so, what are the constraints of this? Things like IPC and
> other stuff comes to mind. 

Just realised I wasn't really clear on this point. Internally
applications don't need any of this /usr stuff to run, only to integrate
with the desktop. 

Assuming it doesn't use the DBUS/Bonobo single instance activation
pattern you can use a combination of /proc/self/exe (+ maybe if I can
get the patch into the kernel /proc/self/exedir), and an obscure feature
of ELF called DT_RUNPATH to make self contained bundles.

DT_RUNPATH lets you insert paths into a binary that the dynamic linker
will scan after LD_LIBRARY_PATH but before the systems global linker
path. The linker expands the magic $ORIGIN keyword into the path the
binary is at.

In autopackage every apbuild compiled binary has the following
DT_RUNPATHS inserted:

 $ORIGIN/../lib
 $ORIGIN/../lib/whatever
 $ORIGIN/../lib/autopackage

Which translates as: always look in $prefix/lib, then look in the
application private directory $prefix/lib/whatever, and finally look in
a global $prefix/lib/autopackage directory where we can drop magic hacks
in future (it's not used today).

This sort of thing is why it's OK to have two versions of the same
program that would conflict in /usr, because when you
run /applications/whatever-2.0/bin/whatever it'll resolve everything
relative to /applications/whatever-2.0 and not /usr.

One complication is .desktop files but the filenames for these can be
randomized.

thanks -mike


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