On Tue, 23 May 2006 14:08:28 +0100, Mike Hearn wrote:
On Wed, 17 May 2006 19:15:10 +0100, Thomas Leonard wrote:
[ problems with self-extracting archives ]
I guess we should take this off-list as it's not Inkscape specific, unless people here are really interested ;-)
However, we don't need to be able to cope with arbitrary autopackages, because there will always be a "packager" who creates the XML description, so something that just happens to work with the existing packages may be good enough. Or perhaps the offset of the payload could be given as a header field?
That wouldn't work either as the payload can be either LZMA or bzip2 compressed, and new schemes might be added in future.
I've added support for .bzip2 autopackages now in our svn version (the interface XML just contains the MIME type and the start offset; extracting this information is done by the publisher using 0publish). Sure, it won't automatically work with all autopackages, but it's up to the person creating the interface file to check that (someone has to sign-off each version anyway).
It *does* work with Jean-François's new Inkscape RPM (thanks!), which installs fine on my Debian/unstable system without needing root access. The (very short!) process of creating the XML file for it is documented here:
http://0install.net/package-inkscape.html
This RPM wasn't built on the normal build system though, so it has some unnecessary dependencies (pangocairo, etc) and is just for testing the binrelloc bit. The 0.44 binary RPM will hopefully work for everyone, so I'm going to wait for that.
Like I said, the contents of the archive even if it could be extracted don't necessarily bear any resemblence to the files that'll actually be installed. They can be post processed in any way in between being decompressed and installed on the users system. We've had to rely on this design several times now to deal with compatibility problems, so your best bet is still just to use apbuild directly (and disable the compatibility features that need post-processing like C++ support).
That would work. I'm trying to avoid the need for upstream authors to provide multiple binaries, though. I guess it makes sense to build the static Inkscape RPM with apbuild, since it's supposed to be as portable as possible...