[gobolinux-users] Source repositories and other suggestions

Michael Homer gobo-users-dufus at wotfun.com
Tue Dec 5 00:31:23 UTC 2006

On 12/5/06, Martin Baldan <martinobal at gmail.com> wrote:
> On 12/4/06, Michael Homer <gobo-users-dufus at wotfun.com> wrote:
> > On 12/4/06, Martin Baldan <martinobal at gmail.com> wrote:
> > >
> > >
> > > On 12/4/06, Michael Homer <gobo-users-dufus at wotfun.com > wrote:
> >
> >
> > 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).
> Nah, I'll fork the Linux kernel, then :D
> Seriously, you make it sound as if I'm asking for something very strange and
> unwanted, but this kind of integration is something many agree is needed.
> KDE has its way of solving it, for KDE apps (a lot of them), Gnome has its
> way of solving it, then there's the Freedesktop project to integrate both
> and the Elektra project to integrate everything (yes, I like the sound of
> the Elektra project, I know it's been proposed here and I know it's been
> rejected because Gobo devs think it's beyond the scope of a single distro,
> but if Elektra is adopted by app developers, it will make it into Gobo.
> That's for another thread).
To  be clear, I still don't think this is useful or worthwhile; that
kind of problem just isn't common enough in the wild to justify those
sorts of large-scale patches. The KDE and GNOME systems aren't meant
to deal with library version problems; they're meant for reporting
bugs in the software - parts where they've coded it wrong. If a
library broke compatibility it's a library bug.
> So, to sum up: We need some convenient way for users to tell about
> application misbehaviours. We can always do it manually, with some simple
> command and the name of the app. The next level of automation would may
> involve wrappers, or little patches for KDE, Gnome and other DEs (somehow
> done on-the-fly thanks to a patch in Compile?), or a test-phase right after
> compilation... what seems clear is that more integration is the future of
> Linux. Meanwhile, we have all these ways for users to report bugs (something
> every distro must do). This information is fed into the compatibility
> database. The more info, the better, but it's not vital that every app has
> an automated way of doing that. It's just desirable.
If you find a bug, report it to the project or distro's bug tracker.
That's what they're for. A massive compatibility database like this
just isn't useful here, because the situation doesn't arise enough
outside of laboratory conditions.

That's why I suggested one of the heavily security-focused
distributions might go for it; it'd be an extension of what they
already do, and conceivably even a part of it. It's not Gobo.

As for the patch policy, if you want to patch something just copy the
patch file into the recipe directory and compile. I could see a use
case, perhaps, for a third-party patch repository that could get some
integration into Compile ("Would you like to apply any of the
following patches? 1... 2... 3..."), but I don't see it being
sufficiently useful to warrant expending time on it (if you're
volunteering, though, I guess go ahead). Otherwise, for the rare cases
where you actually want those sorts of patches, I think sticking the
patch into the recipe is good enough.

More information about the gobolinux-users mailing list