[gobolinux-users] Source repositories and other suggestions

Michael Homer gobo-users-dufus at wotfun.com
Sat Dec 2 09:44:13 UTC 2006

On 12/2/06, Martin Baldan <martinobal at gmail.com> wrote:
> On 12/1/06, Michael Homer <gobo-users-dufus at wotfun.com> wrote:
> >
> > How are you determining what it links against? How are you changing
> > the linking values? Both of those are going to have to be guesses (I
> > guess you could just patch the linker to do it, but I wouldn't want to
> > do that on a system I cared about). The simplest approach is a simple
> > text replacement, but that's obviously going to have problems
> > sometimes, so you'd need to parse out everything and understand it
> > before you changed it. It'd be enormously difficult.
> > -Michael
> >
> I've found the description in
> http://www.dwheeler.com/program-library/Program-Library-HOWTO/x36.html
> >
> >
> >
> >
> >
> > ldconfig doesn't set up the linker names; typically this is done during
> library installation, and the linker name is simply created as a symbolic
> link to the ``latest'' soname or the latest real name. I would recommend
> having the linker name be a symbolic link to the soname, since in most cases
> if you update the library you'd like to automatically use it when linking. I
> asked H. J. Lu why ldconfig doesn't automatically set up the linker names.
> His explanation was basically that you might want to run code using the
> latest version of a library, but might instead want development to link
> against an old (possibly incompatible) library. Therefore, ldconfig makes no
> assumptions about what you want programs to link to, so installers must
> specifically modify symbolic links to update what the linker will use for a
> library.
> >
> > Thus, /usr/lib/libreadline.so.3 is a fully-qualified soname, which
> ldconfig would set to be a symbolic link to some realname like
> /usr/lib/libreadline.so.3.0. There should also be a linker name,
> /usr/lib/libreadline.so which could be a symbolic link referring to
> /usr/lib/libreadline.so.3.
> Isn't it highly relevant for the topic we are discussing? Especially this
> part:
> "I would recommend having the linker name be a symbolic link to the soname,
> since in most cases if you update the library you'd like to automatically
> use it when linking."
>  It seems to imply that you can have the linker name be a symlink to the
> real name, without patching the linker. So, my proposal would consist in NOT
> doing what is described (use the soname to automatically use the updated
> library) Instead, use the real name. This way, there's the drawback that
> every time you update a library you have to recompile all programs that
> depend on this library, but you get the benefit that installing a new
> program can't  immediately affect already installed programs (it can't
> change what the linker names point to), and no patching of each program's
> source is involved. Remember that the online compatibility database would
> tell  each program which real name to use, that's one major benefit. And the
> system would be optional, in the sense that you can always set the linker
> back to the traditional way and recompile every program in your system, and
> you're done.
Patching the linker was an either/or with the rest of it; you could do
it just by patching the linker with some cleverness (and dubious
reliability), or by patching everything else. The problem in the
former is in dealing with shared libraries and performing the
necessary guesswork; the problem with the latter is in finding the
appropriate places to change and in making the changes correctly.
You'd need manual intervention for at the least anything that wasn't
autoconf-based (or some system that could have code written to handle
it), and even with autoconf there's pretty heavy variation in how
things actually turn out. For a lot of libraries you could actually
just use configure parameters (e.g. ./configure
--with-libfoo-dir=/Programs/LibFoo/2.1.1/ ...). Others won't work like
that, so you'd probably want to keep everything handled on the same
(lower) level.

I don't think this is logistically possible, because it would involve
a high degree of manual intervention (if you think it can be fully
automated, go ahead and prove me wrong; I think there's too much
variation). The benefit is also absolutely minuscule - even for
somebody with the resources to make it happen, it wouldn't be
worthwhile. It'd be a lot easier to manage for a fully binary-based
distribution of course, and I could see one of the very security-heavy
ones doing it for the paranoia value.

There may also be problems if a dependent library of Foo is linked
against a different version of Bar than Foo is. That means library
compatibility couldn't be updated until every dependent (and
co-reliant) program was verified as well.

To be honest I'm pretty dubious about how the compatibility database
would really work, but I'm having difficulty voicing why. I guess it's
partly because versions would be marked compatible on an
at-first-sight basis. I might have more to say on that subject, but
I'll have to give it some more thought.

Again, I don't think this is an impossible or bad idea in itself, I
just don't think it's plausible or fitting for Gobolinux. A very
security-conscious, high-resourced, binary-based distribution could
well want to take it on, if they don't already.

More information about the gobolinux-users mailing list