[gobolinux-users] Source repositories and other suggestions
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>
>> Well "linked in" programs are not the same thing as "linked against"
>> programs. You have to separate the libraries that an application is
>> 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
> actually be loaded when I run the executable). But who decides what
> libraries are linked against and who decides what libraries are linked
> 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
> 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
> suggest the corresponding upgrades to the user. These upgrades should be
> reversible, and they may consist of just relinking the application,
> having to upgrade its version (both options should be given). What I
> mean is
> that a given application version, say Firefox 126.96.36.199, could have its
> dependencies file modified over time, to reflect the fact that more
> versions have been tested. So, you could get rid of an old library by
> relinking Firefox 188.8.131.52, 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