[gobolinux-users] Source repositories and other suggestions
gobo-users-dufus at wotfun.com
Tue Dec 5 06:16:24 UTC 2006
On 12/5/06, Martin Baldan <martinobal at gmail.com> wrote:
> On 12/5/06, Michael Homer <gobo-users-dufus at wotfun.com> wrote:
> > 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.
> They wouldn't have to deal with any of that, that's my point. All they have
> to do is trigger an event, or launch a script (with a configurable name) and
> let a script do the rest. They already know when an application fails, all
> that is needed is that they tell it to the script. I think it would be
> interesting for any distro to be able to use this feature with their own
> scripts. Maybe this feature even exists already, I don't know.
> > 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.
> Reporting a bug is a lot of work for the average user. A moment ago we were
> saying that even typing a simple command with the name of the app that
> failed would be a bit too much work. The less difficult it is, the more user
> cooperation you get. Now there are more automated bug reporting tools in
> certain DEs. That's great, but along with the bug report can go a message to
> the compatibiilty database, so that users avoid bad version combinations
> while devs figure out the bugs.
When did we say that? I certainly didn't say that. If you make them do
it when they run it, yes. But just running a "this didn't work" script
with the name of the program to make an automated report is
reasonable: a lot of people still won't do it (which could well be a
deal-breaker; it depends on how many don't), but the barrier is
lowered. Whether it's useful or not depends on the maintainers. It is
liable to generate a lot of repeated or useless reports.
You seem to have missed my actual point with that paragraph, though;
those bug-reporting systems are just that, they're for bug reporting.
So "Metacity crashes if I drag a window off the upper-left corner of
the screen", but not "Metacity doesn't work with some part of my
particular installed system, god knows which". The intent is that
problems in the coding will be reported and fixed.
> You say the situation is rare outside lab conditions. But a few posts ago
> you said it does happens with packaged programs, because binary
> compatibility does break sometimes. And Gobo does have binary packages. This
> scheme may apply to those as well. Besides, once you have R-R names, you can
> build a tree of major-versions from that, where incompatibilities are more
> likely to arise. The R-R name is just the rock bottom, you can build your
> compatibility policy from there upwards, that's the power of it.
It's no more common with packaged programs than with those compiled
from source, excepting when the dependencies in the packagng system
are inaccurate, or multiple distinct packages with the same name
exist. Anyone who's ever tried running a Red Hat system has probably
run into that problem, which is largely a problem with the concept of
that kind of binary-based system.
> > 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.
> I'll give you an example. Let's say that many Gobo users want an Elektrified
> Gobolinux. This requires extensive patching to all applications. Gobo devs
> tell them to ask upstream application devs to do that. Application devs say
> no. The only option they have left is to fork Gobo and create yet another
> distro. But if they can just setup a patch repository for this purpose, with
> Compile having the options as described (and even a variable to do the
> patching by default) then they don't have to fork Gobo, they are still proud
> Gobo users, just with their own set of patches, and they can leverage all
> gobo recipes.
Like I said, I can see a use case for that. If you want to write up a
patch to add it and submit it, and see whether it makes it in. Of
course, they're not really Gobo users, you've still forked it - their
system isn't compatible with a standard system. You're just
piggybacking your fork over the top of an established distribution.
Basically, my overall take on this whole thing is that it's not Gobo.
So your options are to pitch it somewhere else, or fork. But the
impression I get is that nobody's interested. If you don't have the
necessary critical mass it just won't work.
The patch repository idea might make the cut (maybe), so if that's
enough for your needs you might want to look at drawing up a patch to
Compile to add that. I don't think it'd be too complicated. You could
even do it without a patch by using a separate script, I guess.
More information about the gobolinux-users