[gobolinux-users] Source repositories and other suggestions

Michael Homer gobo-users-dufus at wotfun.com
Sun Dec 3 21:15:52 UTC 2006

On 12/4/06, Martin Baldan <martinobal at gmail.com> wrote:
> On 12/3/06, Michael Homer <gobo-users-dufus at wotfun.com> wrote:
> >
> > 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.
> That's the idea. A compatibility table would have as keys the R-R name of
> each application or library, and as values it can have a few fields of
> information about tests (numbrer of possitive tests, number of negative
> tests, approved by a dev?, ...). I don't think you need anything else, but
> of course you can build a tree from that if needed.
The reason I was thinking of a full tree is to make it easier to find
a closest fit solution.
> >
> > 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.
> Well, that's  probably true, but it very much depends on the effort
> required. What I have in mind is that, when an app is still very new (few
> tests), every time a user closes the app, a prompt or a pop-up appears,
> asking "did this app work correctly (yes/no)", so it only takes one click to
> answer. When a few of these tests are done, the pop-ups stop appearing to
> anyone. Of course, users who want it should be able to refuse to cooperate
> and get no pop-ups ever.
That means you're going to have to wrap every program, which means
you're going to have to patch them all individually and manually (how
else will you know which binaries to wrap?). It also won't work on
programs like sed or grep, that are used automatically during
compilation and which will make compilation die if they wait for a
> >
> > 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.
> Ok, thanks for the tips ;)
> > 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.
> > _
> Well, yes, you have the info about sonames-TO-real_names in the filesystem,
> but you need a table of real_names-TO -RR_names, so that you can look up the
> R-R names in the compatibility table.
> At first, the real_names-TO-RR_names table would have null values, and it
> would start replacing them with real values as you compile applications. Or
> you could tell the system to recompile every program, and then have a valid
> table.
> So, it's not that bad, but yes, I have the same kind of feeling. A more gobo
> way would be something like sonames point to real names point to R-R names,
> but this seems to be too disruptive. Maybe there a way to do it. The good
> news is that this is independent from the compatibility table, so we can
> rethink it later.
That sort of database seems kind of... oblique. It is pretty much
necessary to make this work, but it's not really desirable. I guess
it'd be worth looking at how long it actually takes to build these and
consider doing it on the fly. Or maybe saving it into
/Programs/Foo/1.0 somewhere.

Jonatan's scheme would work, but realistically you'd have to do it
manually - just copying/symlinking in the necessary libraries won't be
enough in some cases that rely on knowledge of where they are to find
companion files. There's still the wrapper problem too.

Also, you won't be able to use SymlinkProgram (because all the added
libraries would also try to be installed). It wouldn't be a
show-stopper on its own, because of overwrite protection, but in any
situation where you really did want to overwrite the files for a
program you wouldn't be able to.

More information about the gobolinux-users mailing list