DLL vs Shared Library

[Alan McKinnon]

On Thursday 30 March 2006 22:41, Sergio Duran wrote:
> Hello, everyone,
>
> I'm new to this list and I just go to this e-mail, I'm really sorry
> if I don't know exactly what you're talking about but I'll take a
> wild guess...

Welcome!

> I've been wondering about a new installation scheme, in which
> there's a central database (for example, a text file with:
> lib.so.1:/usr/local/bin/myapp/lib.so.1) with a list of installed
> shared libraries and/or files, when installing an app or library,
> it copies all the files in the installation package, unless there
> is a match in the shared file database, in which case, instead of
> copying the file, it creates a hard link to the file/library.

Hmmm, that sounds way too complex. First off, anything in /usr/local 
should be outside the package manager's control. If you know enough 
to compile stuff and make hardlinks, you already know how to apt-get 
any standard libs it needs.

ldconfig has to index /usr/local/lib for this to work, so hardlinking 
stuff in /usr/local/lib to /usr/lib will break the package manager - 
if the package managed lib is uninstalled the link (and the lib) will 
still exist in /usr/local and still be in ld.so.cache. The package 
manager thinks it's gone, but it isn't. You don't need a database of 
installed libs - there is one already in ld.so.cache

The package manager knows all about dependencies - that's why apps can 
be packages as one .deb for libs and another for the app, with the 
app depending on the libs. This is how you can have Gnome apps run on 
a KDE machine without having Gnome installed - just install the GTK 
and Gnome libs. The same applies to your own stuff in /usr/local - it 
is your responsibility to manually resolve all dependencies as the 
package manager can't help you. You are also expected to not break 
the rest of the system doing this.

> This way the app directory contains all the files it needs,
> including hard links to the libraries, when deleting apps, the
> libraries remain available as long as there is one hard link to the
> file.

As said above the problem isn't deleting the app, it's deleting the 
libs it depends on, leaving a copy that should not be there.


-- 
Alan McKinnon
alan at linuxholdings dot co dot za
+27 82, double three seven, one nine three five