[gobolinux-users] Source repositories and other suggestions
martinobal at gmail.com
Wed Dec 6 02:10:01 UTC 2006
On 12/5/06, Michael Homer <gobo-users-dufus at wotfun.com > wrote:
> 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.
I never said bug reports should be replaced by the less informative
incompatibility reports. All I say is that, if the DE can detect when an app
fails, and launch a bug reporting service, it can also trivially launch an
incompatibility report service at the same time with no additional work from
the user. Bug reports are for developers to read and try to fix bugs,
incompatibility reports are for the compatibility database. Of course
developers are not supposed to figure out bugs from incompatibility reports,
although it might be useful as an early warning, until someone sends a bug
> 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.
If you only use official repos, how can there be distinct packages with the
Besides, doesn't any binary packaging system rely on binary compatibility,
and didn't you say that binary compatibility is easier to break?
And you didn't adress my other point: don't you agree that you can trivially
turn R-R names (a tree of real names) into a tree of sonames? wouldn't that
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.
Well, the idea is that, with the right policy of names and namespaces, users
could easily go to and from different branches without reinstalling the
system, so they would have a very real feeling of being in the same distro.
But I think I should give more details about this in the 'ideas' section of
Gobo, and see what people think.
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.
Yes, maybe a script called PatchCompile, which uses Compile, the original
file and the patches, and then an option in Compile (for instance, Compile
--patch) so that Compile launches PatchCompile and forwards the arguments.
That would be the least disruptive option, I think.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the gobolinux-users