[gobolinux-users] Source repositories and other suggestions
gobo-users-dufus at wotfun.com
Sun Dec 3 23:50:00 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:
> > The reason I was thinking of a full tree is to make it easier to find
> > a closest fit solution.
> That sounds good. I'm not sure how this closest fit search could be
> implemented,or whether it would help or complicate things, but in any case,
> I chose a lisp-like syntax because it readily translates to a tree. The
> alphabetical ordering makes the name unique, so it can be easily indexed in
> a table.
> > 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
> > prompt.
> Well, no way I would propose to wrap every program. Doesn't the system know
> when an application exited abnormally, or when it was closed/killed by the
> user? At the very least, this kind of integration exists at the
> desktop-environment level, and most users have some kind of desktop
The system knows, yes (in a sense, more below), but you're proposing
to have it execute your code when that happens. That's kernel-patch
territory. Otherwise, you've got to wrap them.
At the DE level applications are launched by a wrapper (the shell). So
the shell can display indications that something's opening, or that
it's done, because you told the shell before it was launched (by
picking from a menu, say) and because the shell is the parent process
of the application.
> BTW, I'm thinking of an option for user who don't want to be bothered: The
> system sends a negative vote if the app exits abnormally. If the user closes
> the application, the default is to send a possitive vote. If the user closed
> it because it was misbehaving, he can easily send a failure report with the
> name of the app, and this cancels the positive vote.
Sending a negative vote if the program ends abnormally is
semi-reasonable; the other's a bit of an assumption. It's a bit of an
assumption either way really; what about programs that are expected to
return a failure status code in normal operation? Examples: grep (no
match), gcc (compile failed), anything with mandatory parameters.
> > 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.
> Yes, that's kind of what I proposed in my previous post. (for instance,
> > 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.
> > -Michael
> I see a partial analogy here, maybe it's not correct but anyway: some
> applications make assumptions, in their installation scripts, about where
> other programs (dependencies) are, and Gobolinux devs have to edit them to
> change those assumptions. Individual binaries make assumptions about where
> other binaries of the same program are located. These assumptions could also
> be changed (in principle), but it would be much more hackish, because they
> are universally considered safe assumptions, and there's no clean way to do
> it, no equivalent of "--prefix"(or is there one?). So, I think it's safer to
> store this info under /Programs/foo/1.0/Resources.
It's not just binaries; look in /usr/lib/pkgconfig, for example. While
all these can be worked around in specific cases, in the general case
it requires a lot of intervention. It's a good solution for if you're
only treating a few applications this way for its simplicity, but it
doesn't scale well.
Another potential problem is subprocesses. You really do have to wrap
everything to make that work, for if a subprocess needs a different
library path than its parent.
More information about the gobolinux-users