[gobolinux-users] Source repositories and other suggestions

Michael Homer gobo-users-dufus at wotfun.com
Sat Dec 2 23:22:45 UTC 2006

On 12/3/06, Martin Baldan <martinobal at gmail.com> wrote:
> On 12/2/06, Michael Homer <gobo-users-dufus at wotfun.com > wrote:
> >
> > That's basically what I suggested before, shifting the logic into the
> > compile/install stage. It's both plausible and possible, and I don't
> > see any reason you couldn't do it. There are still a few potential
> > problems, but they're not technical ones now: that online database is
> > going to be pretty big, and grow pretty quickly as people upgrade, and
> > the system only works if enough people (a critical mass) bother to
> > mark versions as compatible. That can't really be automated unless you
> > install wrappers for everything.
> >
> My proposal has been evolving as I was getting a grasp of how shared
> libraries are actually organised, and your suggestion is indeed more
> realistic. I don't care so much for flexibility as I do for stability and as
> little disruption as possible.
> As for the problem of the growing database, yes, the potential namespace of
> R-R names is HUGE, but notice that the database doesn't have to list them
> all, just the ones that have been tested. Most of them will never be tested,
> as the app version in the trunk of the dependency tree will become obsolete
> before that happens. If it becomes too big anyway, there may be provisions
> for that, for instance, very old app versions may have all but their latest
> entries removed (where each entry is actually one R-R name for the
> application itself, if you think of it). Besides, old entries may be taken
> offline and only used if needed by developers or requested, and this would
> also prevent the whole historical burden to go into each gobo installation.
> Of course, all this measures should be automated according to a policy.
The "most of them will never be tested" part might be a little bit of
a problem; it means people will always be running into untested
versions, and they'll either always be upgrading or just learn to
ignore it (which will populate the database, so a certain level of
ignoring is required).

The R-R names would really need to be trees, rather than flat strings,
to cover the whole range of possibilities. At the very least they need
to be a set as opposed to just 'foo-1.0.so-linkedwith-...', to handle
> Regarding user cooperation, I'm thinking it could be integrated in the
> recipe uploading scheme.
Wouldn't that mean that each program only ever gets tested with one
set of installed dependencies?

I'm still not convinced the benefit is worth the effort, but if you
can make patches (or better yet, at least to begin with, wrappers for
proof of concept) to implement all of that optionally, go ahead. It'd
be worth seeing if other people are interested in it first.

More information about the gobolinux-users mailing list