[gobolinux-users] Source repositories and other suggestions

Michael Homer gobo-users-dufus at wotfun.com
Wed Nov 29 23:01:57 UTC 2006


On 11/30/06, Martin Baldan <martinobal at gmail.com> wrote:
>
> 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?
That's untrue. XChat is linking against OpenSSL, which does not have
backwards-compatible libraries (i.e., they're all, always, fully
versioned). OpenSSL is a special case in that way.

Most programs will link (at runtime) against the library name -
/lib/pango-1.0.so.0, which may be a symlink, or may be a real file
that's replaced with new versions. They do not follow the symlinks at
compile-time and resolve a fixed version.
>
> 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.
It is very rare for an application to link against a highly specific
version like that. The libraries DO have exactly the same name, as far
as they're concerned.
>
>  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.1
> are 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.
XChat developers do not ask for version 0.9.6; OpenSSL breaks
compatibility with every numbered release, deliberately. XChat can
either link against 0.9.6, and work until that version is uninstalled,
or link against libssl.so, and work until there's a version upgrade
and that symlink points somewhere different.

> 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
> libraries.
That's not how it works. You're going to have to patch every program
on your system to resolve symlinks and link against a specific
version.

> 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.
You could do this part, and have them not be installed unless there's
verified compatibility. You can't do it on a program-by-program basis.

I think a large part of the misunderstanding here is that you're
thinking that applications pull in a fixed library version at compile
time; they don't. They link against a name.

For example, Firefox on my (Gentoo) system links against libz.so.1,
which it finds at /lib/libz.so.1. /lib/libz.so.1 is actually a symlink
to libz.so.1.2.3. If I upgrade libz, Firefox will start using the new
version as soon as I restart it. I could even have two versions
installed at once, and flip the symlink between them - Firefox will
happily use either.

If I'd compiled it statically, it would keep using the same version as
when I compiled it, because it would all be included in the binary,
but that's all.
-Michael


More information about the gobolinux-users mailing list