[gobolinux-users] Source repositories and other suggestions

Michael Homer gobo-users-dufus at wotfun.com
Wed Nov 29 00:24:17 UTC 2006


On 11/29/06, Martin Baldan <martinobal at gmail.com> wrote:
> Let's see if I got it: "linked against"  libraries are the ones  the
> executable will "ask for" when run; that is, the program will search for a
> file in a specific location, and this is embedded in the program's object
> code. But in this location there is a link pointing somewhere.
> SymlinkProgram  decides where this link should point to (the "linked in"
> library) and creates the link.
On another system, the /usr/lib/foo.so.0 file would just be overwritten.

>  For instance, you say:
> > For example my firefox links against
> > /System/Links/Libraries/libpangocairo-1.0.so.0 (part of
> Pango), so I can
> >
> > use any version of Pango that has that library version and the one linked
> > in atm is which firefox would use, as the link
> >
> >
> > /System/Links/Libraries/libpangocairo-1.0.so.0 is updated
> to reflect which
> > version of Pango that is active. So far I can select which version to use.
>
>
> So,  /System/Links/Libraries/libpangocairo- 1.0.so.0 , the
> "linked against" library, is just a link, regularly updated to the "active"
> version, the real library that will be used, right? For instance, in my
> system it now points to
> ../../../Programs/Pango/1.13.2/lib/libpangocairo-1.0.so.0
> , which in turn points to libpangocairo-1.0.so.0.1302.0 , which I guess is
> the actual library that will be loaded.
>
> Now my point is, even if Firefox does not require a specific version of
> libpangocairo (such as libpangocairo-1.0.so.0.1302.0) but only a version
> range (such as libpangocairo-1.0.so.0 ), I think there could be a file (or a
> database) with updated information about which specific versions of the
> libpangocairo-1.0.so.0 version range have been actually tested (even users
> could automatically help with the tests, and create a shared pool of
> knowledge about actual, tested compatibilities). So, if
> libpangocairo-1.0.so.0.1302.0 has been tested with firefox, it can be
> automatically "linked in" by SymlinkProgram . If none of the  available
> versions have been tested, the system may warn the user, who would decide
> what to do (try untested libraries or wait until they are tested). The
> update manager would check for newly tested library versions from time to
> time, and either update the links automatically or ask the user. I think
> your XChat example illustrates, rather than contradict, this concept.
>
> In other words, what SymlinkProgram would do is that, instead of  just
> "linking in" the libpango version found in /Programs/Pango/current , it
> would also check that this version is present in, say,
> /System/Links/TestedWith/Firefox/2.0/Programs/Pango/current
> (if you are compiling Firefox2.0)
So you're envisaging a system where you have to re-run SymlinkProgram,
for every installed program, every time you run or compile something?
I don't see how else you can effect this (on Linux; Plan9 and possibly
Hurd could do it).

On another (i.e. non-Gobo) system, /usr/lib/libpangocairo-1.0.so.0
would just be overwritten with a new symlink to
libpangocairo-1.0.so.0.1302.0 when you installed this version. There
should be guaranteed compatibility for all versions holding that
symlink; if not, it's the library that's broken and it needs to be
fixed. Libraries with the same name should hold ABI compatibility.

XChat fails in that case because OpenSSL imposes stringent versioning;
there's a new library version for every numbered release. I believe
there are security concerns involved with that. When you compile
XChat, it finds the current version of OpenSSL and links against it.
Minor versions (0.9.8c/d/e) do maintain compatibility, I think, but
0.9.9 would not. There's an additional level of paranoia there that
you don't get with others.

It mightn't be a bad idea for Compile or SymlinkProgram to give a
warning, and possibly run a check on what linked against the old
version when OpenSSL is upgraded. That would avoid people accidentally
breaking things by uninstalling old versions that were still in use.
-Michael


More information about the gobolinux-users mailing list