[gobolinux-users] Source repositories and other suggestions

Martin Baldan martinobal at gmail.com
Sat Dec 2 17:24:01 UTC 2006


On 12/2/06, Michael Homer <gobo-users-dufus at wotfun.com> wrote:
>
>
> 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.


It looks like patching the linker would be cleanest. Can you think of ways
in which the guesswork could fail? I mean, if foo.so.3 is safe, doen't it
mean that for all X, foo.so.3.X is also safe?


>
>
> 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.


Why do you insist that the benefit would be small? It's not just security
paranoia, shared libraries can be a royal PITA because of compatibility
issues (minor versions being accidentally incompatible). If minor versioning
worked so well in practice, things like PBIs would not exist. In Linux,
installing a new application can (and often does) break other applications
you installed before. They always say you can choose between the rock-solid
stability of statically linked libraries, or the memory benefits of shared
libraries. What if you could have both?

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.


I'm not sure what you mean here, but notice that every "atom" of
information that is uploaded to the database would only refer (recursively)
to real names, not to sonames. I don't know what you mean by "at first
sight", but in the worst case, it would always be at least as reliable as
the official minor version criterion, since that would be the maximum
compatibility allowed in tests.

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.
>

If it can't be automated, clean and optional, in a  very gobo-like spirit, I
don't want it. It should work as an option in Compile, something like
choosing between "Compile --realnames appfoo" or "Compile --sonames appfoo"
and having a global variable to state which is the default behavior. The
compatibility database would be just an aid for safe update automation, but
it would be easily overriden by the user without breaking anything (in fact
that's the way the database would grow).

I will be busy for a few days, but when I have the time, I'd like to look
further into the matter, read more about this, ask a few more questions and
then ask for something like this as an optional feature, unobstrusive with
the general Gobolinux workings.

--Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.gobolinux.org/pipermail/gobolinux-users/attachments/20061202/420cdb70/attachment-0001.htm 


More information about the gobolinux-users mailing list