[gobolinux-users] Source repositories and other suggestions
martinobal at gmail.com
Sat Dec 2 23:04:11 UTC 2006
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.
Regarding user cooperation, I'm thinking it could be integrated in the
recipe uploading scheme.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the gobolinux-users