<br><br><div><span class="gmail_quote">On 12/5/06, <b class="gmail_sendername">Michael Homer</b> &lt;<a href="mailto:gobo-users-dufus@wotfun.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">gobo-users-dufus@wotfun.com
</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>You seem to have missed my actual point with that paragraph, though;<br>those bug-reporting systems are just that, they're for bug reporting.<br>So &quot;Metacity crashes if I drag a window off the upper-left corner of
<br>the screen&quot;, but not &quot;Metacity doesn't work with some part of my<br>particular installed system, god knows which&quot;. The intent is that<br>problems in the coding will be reported and fixed.</blockquote><div>


<br>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 report.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>It's no more common with packaged programs than with those compiled<br>from source, excepting when the dependencies in the packagng system
<br>are inaccurate, or multiple distinct packages with the same name<br>exist. Anyone who's ever tried running a Red Hat system has probably<br>run into that problem, which is largely a problem with the concept of<br>that kind of binary-based system.
</blockquote><div><br>If you only use official repos, how can there be distinct packages with the same name?<br>Besides, doesn't any binary packaging system rely on binary compatibility, and didn't you say that binary compatibility is easier to break?
<br>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?<br></div><br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Like I said, I can see a use case for that. If you want to write up a
<br>patch to add it and submit it, and see whether it makes it in. Of<br>course, they're not really Gobo users, you've still forked it - their<br>system isn't compatible with a standard system. You're just<br>piggybacking your fork over the top of an established distribution.
</blockquote><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">Basically, my overall take on this whole thing is that it's not Gobo.<br></blockquote>

<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">So your options are to pitch it somewhere else, or fork. But the<br>impression I get is that nobody's interested. If you don't have the
<br>necessary critical mass it just won't work.
</blockquote><div><br>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.
<br>&nbsp;</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">The patch repository idea might make the cut (maybe), so if that's<br>enough for your needs you might want to look at drawing up a patch to
<br>Compile to add that. I don't think it'd be too complicated. You could<br>
even do it without a patch by using a separate script, I guess.<br>-Michael</blockquote><div><br>&nbsp;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.
<br><br>--Martin<br></div></div>