[gobolinux-users] Source repositories and other suggestions
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
> > > the user when an upgrade is recommended. Just a little overhead at
> > > 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
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
> 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.
More information about the gobolinux-users