[rox-devel] Injector

[Tony H. <h...@re...>]

I decided to give the injector a try which meant I had to make some
AMD64 packages for it. If anyone's interested, the partial results are
at <http://www.raelh.plus.com/rox0/>. You'll probably have to download
the interfaces and use `0launch --feed' on each one. And if you use
AddApp or otherwise make OroboROX available in some location other than
its cache so that you can configure it, you'll need to copy AppInfo.xml
manually, because AddApp has taken it into its head not to use
OroboROX's AppInfo.xml but to replace it with one that looks as if it's
filled in from a simple template that's missing the extra menu item(s)
etc. And that was basically the last straw that made me give up on
Injector.

Other problems I had were:

Whenever AddApp had a problem it kept reporting:

Errors from command '['0launch', '-d', '--', 'http://rox.sourceforge.net/2005/interfaces/OroboROX']':
/home/tony/.cache/0install.net/implementations/sha1=ffb6f0d649020819c8d04f90b5fe6b3ff6030fe7/dialog.py:18: GtkWarning: Theme file for default has no name

  gtk.Dialog.show(self)

instead of whatever the problem really was. After popping up that error,
it would quite often appear to work OK if I tried clicking the button
(I've forgotten what label it had - I've had to completely expunge the
injector to make sure ROX-Session will work correctly again) in its
initial window.

I tried repacking OroboROX a couple of times to see if I could fix its
AppInfo.xml problem. 0launch wouldn't download the new version until I
deleted the old one from the cache. Even 0launch --refresh just tried to
rerun the cached OroboROX. I've just thought: I was using the URL for
the original interface at rox.sf.net, not mine that overrides it.
Perhaps when refreshing/checking, 0launch neglects to check whether the
interface has been overridden with --feed and only checks the
interface/implementation given? If so, I'd consider that a bug.

I also tried removing my feed, because the main one has an x86_64 binary
as well as ix86, albeit an old version, so it should have been able to
use that. But then 0launch complained of something like the
implementation being missing. Sorry I can't remember the exact error.

Some suggestions:

I think specifiying the arch should be mandatory, including (eg) "any"
for entirely non-compiled packages, and "src", and providing a source
implementation should be mandatory for compiled languages. People
providing arch-specific feeds for existing packages can simply copy the
source implementation tags from the original interface if they haven't
had to patch the source.

And for packagers who have had to patch the source, maybe a "patch" tag
would be useful instead of having to supply the entire source tarball
again. OTOH, this could create dependencies on specific versions of the
original package, which might not be desirable.

0launch should automatically ask if you want to add a feed when it
encounters a "feed-for" tag instead of users having to run --feed
manually. And even if it stays manual, it would be nice if it could work
on interface URLs instead of relying on the user downloading them and
removing the GPG bits manually.

-- 
TH * http://www.realh.co.uk