[gobolinux-users] Source repositories and other suggestions
gobo-users-dufus at wotfun.com
Wed Dec 6 05:05:57 UTC 2006
On 12/6/06, Martin Baldan <martinobal at gmail.com> wrote:
> 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
There's no reason to suspect the error is due to an incompatibility.
In the trivial case of a report just saying "program X doesn't work",
there could be merit - but it obviously works for somebody, or it
wouldn't be in the repository to begin with. You may well just have
run into a coding bug that comes up only rarely, which usually won't
be enough to stop somebody else from using it. There's a judgment call
to make there.
> > 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
> same name?
There can't - but people tend not to use only official repositories,
because they want to use something newer than that found there, or
some RPM they found on the internet. There's also the case of
self-compiled programs that've been `rpm -i`d. That happens to add and
remove functionality, or to install something that isn't yet
If they do use only official binary repositories they won't have this
problem unless the maintainers mess something up.
> Besides, doesn't any binary packaging system rely on binary compatibility,
> and didn't you say that binary compatibility is easier to break?
No. Problems occur when the dependencies within the RPM aren't
correct, or something different has been installed under the same
name. You run closer to the wind if you update only parts of your
> 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
> be useful?
Within the context of this, yes, but I don't really see how otherwise.
> > 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.
Go ahead with that, I'll be interested to see it. I just don't quite
see how it's going to work. Debian manages it, sort of (if I
understand what you mean), but only within their own sphere of
influence. Even apt-get dist-upgrade to Ubuntu is problematic.
> > 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.
> > -Michael
> 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.
What I was thinking of is just pulling in the patches to the
appropriate recipe directories and letting Compile do its magic. This
way would work too, as would what Hisham suggested in adding another
repository. I think you'd have to copy over the recipes you wanted to
patch in their entirety, rather than just adding the patches (that
depends on how Compile deals with that; it might not be necessary),
and you'd need yet another repository for every different choice or
patch-set, but it is possible right now with current tools.
More information about the gobolinux-users