[gobolinux-users] Source repositories and other suggestions

Martin Baldan martinobal at gmail.com
Wed Nov 29 20:26:29 UTC 2006

On 11/29/06, Michael Homer <gobo-users-dufus at wotfun.com> wrote:
> On 11/29/06, Martin Baldan <martinobal at gmail.com> wrote:
> >
> > No, I'm just proposing additional verifications ("tested compatibility"
> > requirements) at compile time, and a lightweight daemon that regularly
> > checks for updates in the "tested compatibilities" information, and
> informs
> > the user when an upgrade is recommended. Just a little overhead at
> compile
> > time and no overhead at runtime (plus the small overhead of the daemon).
> If different programs need different specific versions, you're going
> to have to re-SymlinkProgram them every time you run them. If they
> don't, there wasn't a problem to start with.

This makes no sense to me, and contradicts what you and others have been
saying. There must be a big misunderstanding here. In Gobolinux, AFAIK, you
can have different versions of a library, each one used by a different
program. For each program, at compile time you decide which library version
it will use, and this will not change until you recompile the program, so
you don't re-symlink anything when you run the program. The XChat example
illustrates this. Do you agree on this?

Forget about Plan9, private filesystem views and all that, what I say is
much more simple.
Of course I agree that if two libraries have EXACTLY the same same, down to
the lowest sub-version number, then they are one and the same library,
otherwise the Linux library namespace would be broken and useless. This can
be safely considered fact.

 Now comes the assumption: In Linux, different libraries with the same MAJOR
version number are supposed to keep backwards compatibility. But this is not
fact, just an assumption: it's different code with a different name, and
there may be incompatibilities only discovered when those libraries are used
by some particular applications. Different application developers have
different levels of confidence about this assumption: Firefox developers are
confident, so, they just ask for libpangocairo-1.0.so.0, and implicitly
accept that libpangocairo-1.0.so.0.1302.0 and
libpangocairo-1.0.so.0.1302.1are both valid. XChat developers are less
confident, and they ask for
libssl.so.0.9.6 (a deeper level of version numbers). In any case,
application developers CAN'T KNOW whether future versions of the libraries
they require will actually be backwards compatible with their application.
They are supposed to be, but I don't think they are tested with every
program on earth that may depend on them. Bugs happen.

What I say is that Gobolinux need not restrict its level of strictness to
that of the application developers. It can be far more strict, and then
lighten up as users test the new versions and upload their results.

Let's say Firefox 2.0 was released today and I'm the first Gobolinux user to
try it. The system warns me "No Gobolinux user has compiled this program
before". When I compile Firefox, it says "I need libpangocairo-1.0.so.0", so
I give it what I have, libpangocairo-1.0.so.0.1302.0. Then I run Firefox and
it works, so I click a button which says "successful test". This sends a
message to an online database (and the information is also kept in my
system, of course). An hour later, another Gobolinux user is the second one
to compile Firefox. When he compiles it, it will say something like "I need
libpangocairo-1.0.so.0, any subversion will do, but I have only been tested
in Gobolinux with libpangocairo-1.0.so.0.1302.0". Then, user #2 can choose
to get this library version, or he can choose to try another supposedly
compatible, untested version. If he does the latter, then the third user to
compile Firefox will have two "safe", tested library versions to pick from,
and so on. Since both are tested versions, user #2 can safely tell the
system to always use the latest tested version, so that he doesn't have to
decide for every library.

And once the program is compiled, the "linked in" libraries stay linked in,
they are not replaced (at least) until the program is recompiled, so if it
runs once, it will not stop running because of some change in its linked

The upgrade manager would only check which libraries have been tested in
Gobolinux, from time to time, and suggest recompilations when new versions
have been tested. It would not touch any library links.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.gobolinux.org/pipermail/gobolinux-users/attachments/20061129/80936cd2/attachment.htm 

More information about the gobolinux-users mailing list