[gobolinux-users] Source repositories and other suggestions

Michael Homer gobo-users-dufus at wotfun.com
Sun Dec 3 02:41:49 UTC 2006

On 12/3/06, Martin Baldan <martinobal at gmail.com> wrote:
> On 12/3/06, Michael Homer <gobo-users-dufus at wotfun.com> wrote:
> > 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).
> Well, here is where  a smart update manager would help. It would take note
> of all possible updates and recommend batch, en masse updates from time to
> time. The bulk of these batch updates would be done in the background, then
> the user would be asked for permission to replace old installed libraries
> with the new, already compiled ones.
Hmm. That's an interesting idea.
> > 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
> > ordering.
> But you can map trees to strings, and make the sub-nodes of a node be
> ordered alphabetically (ASCII order). Having a unique name simplifies
> things. For instance, if you let me use brackets,it would look like:
> (app1 (lib1 (lib3 lib5 lib6 ) (lib4 lib7 lib8)) lib2)
> Which means app1, linked against lib1 and lib2, where lib1 is linked against
> lib3 and lib4, where lib3 is linked against lib5 and lib6, and lib4 is
> linked against lib7 and lib8.
Yeah, I was thinking that that's how they'd actually be transmitted.
It makes for a complicated search though, which is why I thought using
a tree would be easier. I guess it isn't actually necessary to do
anything beyond a yes/no result for any one set.
> > > 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?
> No, I didn't mean it so literally. Whenever a recipe is uploaded, indeed a
> test is also generated. But it would be also possible to generate tests
> without generating recipes. I mean that recipe uploading should (and
> probably will) be more automated anyway, so from a user POV, uploading a
> recipe and uploading a test would be hardly distinguishable and trivially
> easy to do. The same kind of prompt/pop-up after compilation and the like.
> If recipe uploading is managed by automatically sending a mail, then test
> uploading can be managed in the same way, etc.
What I was getting at is that people will just accept the test that
came with the recipe, and not bother contributing more until a new
version comes out.
> > 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.
> When I have the time, in a few days, I'd love to try to figure that out. I
> guess I would have to learn quite a lot first, though, but the first step is
> to make sure it's not an pointless thing to do. Any kind of help or
> suggestions are welcome ;)
I'm not sure it would be that difficult to do a simple version of it.
It boils down to recursively running ldd and creating a tree. I guess
parsing out the dependencies and then building the hypothetical
what-if-I-install-X would be a bit more complicated though. If you
know Ruby, looking at some of the code in Freshen might help, or in
Manager, although neither of them addresses the bulk of what you'd
need here.

Is this going to require some sort of local database of what
everything is compiled against? That sort of goes against the
filesystem-as-package manager philosophy too.

More information about the gobolinux-users mailing list