[gobolinux-users] Source repositories and other suggestions

Michael Homer gobo-users-dufus at wotfun.com
Mon Dec 4 04:21:30 UTC 2006

On 12/4/06, Martin Baldan <martinobal at gmail.com> wrote:
> On 12/4/06, Michael Homer <gobo-users-dufus at wotfun.com> wrote:
> >
> > I don't think you really have a choice. Doing it properly by patching
> > the kernel would be difficult to impossible, and I certainly wouldn't
> > use a kernel patched to use X.
> I was not thinking of the kernel directly drawing a pop-up, just sending an
> event, or a message, or changing a global variable, something simple.
So you're implementing a substantial kernel patch (there's a lot of
logic to go in there) as well as a daemon to listen to it. Fair
enough, but it's not going to be easy, and the barrier of entry is
pretty high. Not a lot of people are willing to futz with their

To be clear though, this will never, ever make it into Gobo, unless
you manage to get the patch included in the vanilla kernel. Gobo does
bug-fix patches only (needing the FHS links is a bug).
> > So you're manually patching all shells, command-line and desktop?
> > Well... good luck with that, then. Pretty unlikely to make it into
> > Gobo, though. And all the other problems with automatic detection
> > still apply.
> Oh, come on, some day Gobo will need custom  error messages  in their most
> used desktops environments. All distros do that. If this needs doing patchs
> to, say, kde, it will be done. You can keep the unpatched kde, I install the
> patched kde and everyone's happy :D
No, it won't. And nobody's going to maintain those patches. Nor are
there going to be two parallel versions of KDE to install. The same
applies regarding patches as above - if you can automate it (via a
patch to Compile or similar), it's possible, but it's not really
> > GNOME and KDE have back-handed tricks to do those popups for their own
> > applications that would require patching to implement elsewhere. They
> > also do a little bit of guesswork.
> So, KDE only needs a little bit of patching, so that every time it will show
> an error popup, it sends a negative vote.
Plausible, but it really only works well for their own apps (at least
for GNOME, bug-buddy does its fancy stuff for GNOME apps only). That's
still a sizable chunk of them though, so it COULD be enough if those
are the only ones you care about.
> > No matter how you do that, you're going to have to do a lot of
> > patching - whether it's to add a wrapper for everything or to make
> > them hook in to another system, or to add a chunk of guesswork logic
> > into all the shells. The latter two aren't really plausible. Adding
> > wrappers to everything would be the easiest way to do it.
> But  it doesn't seem scalable. How easy would it be to add those wrappers?
> Can it be automated?
None of this can be automated fully. The wrappers themselves wouldn't
be complicated, because you'd just write one main launcher and the
wrappers would be a couple of lines to call that.

Like I said, if you did it as a patch to Compile you might have a shot
of it getting in. Doing the wrappers in that case wouldn't be too
hard, since you're already maintaining a compatibility database - just
keep another one that stores package->wrapped executables data. You'd
just stick the appropriate name into the wrapper, or even do it by
renaming on a standard scheme and leave the wrapper unchanged.
> > One simpler way to do it: You could make applications launch
> > immediately after compiling to test (like installers do on Windows).
> > There's still the issue of knowing which binary(ies) to run, but
> > you've got all the logic in one place and it's not too unexpected that
> > it'd be there. That could all be architected fairly unobtrusively to
> > people who didn't want to use the system.
> I don't think that fills the bill, because sometimes several applications
> are affected (remember we talked of batch updates?) and users can't be
> expected to try them all on the spot.
It's maybe the best way of doing it so far, but yes, if you do a bulk
untested update you'll have a lot to test. People who do this can be
expected to perform a little testing occasionally though, and it
wouldn't take that long. You still have to know which ones to launch,
which is slightly simpler than doing wrappers.

Also, how are you going to deal with programs that are never directly
called by the user? I'm thinking of ones called in the compilation
process, but there are others, like servers.

More information about the gobolinux-users mailing list