symlink app lib to common libs

[Jonas Sundström]

Joerg Sonnenberger <joerg at xxxxxxxxxxxxxxxxx> wrote:
> On Thu, Apr 28, 2005 at 09:00:43AM -0500, Walter wrote:
> > Then THOSE libraries could be placed directly in the lib
> > sub-dir, rather than a symlink, could they not?  In fact,
> > don't even bother with symlinks for the common libraries,
> > but just add (something like) "./lib' in front of the
> > global library path(???), to keep the non-base libs out
> > of /usr/local/lib. (Can this be done?)
> 
> No, this is a invitation for security problems. The whole
> argument boils down to BeOS (and OS-X for that matter)
> normally include all the libs with the program, 

They can, but very few have to include anything at all, 
since the "base" libraries provide pretty much all you need.

You make it sound like BeOS is the King of Bloat. :))
Quite the opposite. MacOS X holds that title...

> you can do
> the same for UNIX, but it is normally not wanted. It's not a
> hack, actually, it's very easy to write a few shell scripts to
> compile and install e.g. Apache that way.

Wrapper scripts are a pet peeve of mine.

They may be ok in a primarily C, CLI-oriented environment,
but they prevent BeOS GUI apps from being "good citizens".
 (Like the version of Mozilla I'm using.)

Sure, argv[] can be propagated through the wrapper, but a
shell script can't hold the necessary application metadata 
(supported filetypes, launch flags, etc) by which the system
"sees" the application (using indexed filesystem attributes),
and by which the system knows what filetypes the 
application handles, what launch flags are set, etc.

And, most importantly, the BeOS C++ API provides a non-argv
document launch mechanism that can't be passed through
a wrapper script. 

Anyway, enough BeOS. :P

About including the libs. If app/lib was supported, how is it
any harder to replace an old or insecure "libfoo" in all your
app/lib folders than it is to replace it in one shared lib folder?

find /usr/local/encap/ | grep libfoo

(BTW, I had a look at encap/epkg. 
Syllable uses such a system for its unix packages.)

Naturally allowing libs to be stored in multiple places
increases the potential of actually having multiple versions,
but is that in itself a security problem?

Isn't multiple versions of apps and libraries
one of the explicit goals of the desired system?

I believe what is needed is proper dependency metadata updates, 
(separate from the package, or port), so that a lib can be upgraded in 
it's global capacity, and the system can (later) find out from such a 
metadata update that application Joobar
is broken with the new lib version and offer an app-local lib rollback.

Such metadata updates should include x-works-with-y, x-works-not-with-y 
relationships, as well as security advisories, providing the admin with 
useful information about the set of apps that are currently installed, 
and also setting the stage for "preflight" information on upgrades and 
installs. (Is anything likely to break if I upgrade X? How will the 
water ripple?)

Are there any such packaging systems out there,  
keeping the metadata separate from the packages, 
allowing disjoint metadata updates?

/Jonas Sundström.                     www.kirilla.com