[gobolinux-users] Source repositories and other suggestions
martinobal at gmail.com
Tue Dec 5 01:17:19 UTC 2006
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.
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.
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the gobolinux-users