[gobolinux-users] Source repositories and other suggestions

Jonas Karlsson jonka750 at student.liu.se
Tue Nov 28 12:58:37 UTC 2006

On Tue, 28 Nov 2006 02:25:40 +0100, Martin Baldan <martinobal at gmail.com>  

> On 11/28/06, Jonas Karlsson <jonka750 at student.liu.se> wrote:
>> On Tue, 28 Nov 2006 00:14:18 +0100, Martin Baldan <martinobal at gmail.com>
>> wrote:
>> Well "linked in" programs are not the same thing as "linked against"
>> programs. You have to separate the libraries that an application is  
>> linked
>> against and what libraries that are linked in in GoboLinux.
> Then I guess I want to know what libraries are linked in (the ones that  
> will
> actually be loaded when I run the executable). But who decides what
> libraries are linked against and who decides what libraries are linked  
> in?
> And does SymlinkProgram know  about this?
Linked in libraries = the libraries that are made available by  
Linked against libraries = the libraries the binary is compiled against

The libraries that are loaded are the versions that the executable is  
compiled against, in my example firefox loaded the file  
/System/Links/Libraries/libpangocairo-1.0.so.0. This is decided by 'ld'  
during the linking fase of the compilation and cannot be changed (unless  
one recompiles firefox).

However both Pango 1.11.2 and 1.14.2 have the libpangocairo-1.0.so.0 file,  
so which version of Pango is used is decided by SymlinkProgram (and is  
morespecifcally the version listed as Current in the /Programs/Pango  
directory). Which version of Pango that is used (between these two) does  
not matter in this case, as the version number of the library is the same  
- Have you noticed the numbers and dots at the end of the so-file?  
Libraries can have versions as well, describing API compatible libraries  
(same library versions).

>> Fortunatly most apps are not that specific, but problems can arise when
>> one makes major version upgrades.
> Well, I would prefer that they are totally specific in the sense that  
> they
> only accepted tested versions. I think that, for the desktop, most of the
> times consistent reliability is more important than timely upgrade.  
> Then, an
> "upgrade manager" can find out when an older version of a library is not
> required any more (but maybe it's still being used!) by any application  
> and
> suggest the corresponding upgrades to the user. These upgrades should be
> reversible, and they may consist of just relinking the application,  
> without
> having to upgrade its version (both options should be given). What I  
> mean is
> that a given application version, say Firefox, could have its
> dependencies file modified over time, to reflect the fact that more  
> library
> versions have been tested. So, you could get rid of an old library by  
> just
> relinking Firefox, instead of upgrading to Firefox 2.0.

It's not that simple. I just found an IRC client, XChat, that I can use as  
an example. XChat can be compiled against any version of OpenSSL above  
(and included) 0.9.6. However the binary produced needs the exact version  
of OpenSSL that was used during compile time. For the XChat package that  
was in the GoboLinux package store that would be OpenSSL 0.9.6.

Say that I want to install the XChat binary, so InstallPackage also  
installs OpenSSL 0.9.6 as that was needed for me to run XChat. Later I  
install the OpenSSH 4.5 binary package, which needs OpenSSL 0.9.7 so that  
is installed as well. Now, even thought XChat can be used with OpenSSL  
0.9.7 (but that's only possbile when compiled against that version of  
OpenSSL), I still can't remove OpenSSL 0.9.6, since then I would not be  
able to run XChat. This is because Xchat needs the file libssl.so.0.9.6  
(notice the library version number*) and that is only available in OpenSSL  
0.9.6. But it doesn't matter, because I can have both OpenSSL 0.9.6 and  
0.9.7 installed at the same time and this will make both XChat and OpenSSH  

So updating binaries is not easy. On one hand I could easily remove any of  
the Pango versions I had and firefox would still work, because the library  
version was the same in both versions. But for XChat I could not install  
OpenSSL 0.9.7 and then remove OpenSSL 0.9.6. Deciding which binaries that  
works with what libraries is very individual and cannot easily be done.

There is an idea on how to suggest removal of "dead" libraries, but the  
functionality is not implemented yet, afaik.


*) sometimes the library version correspond to the application version,  
but that isn't necessary true.
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

More information about the gobolinux-users mailing list