Hi all,
I'm Thomas Leonard, one of the main developers of the ROX desktop[1]. I'd like to make Inkscape the default vector drawing application for ROX.
We provide a "ROX-All" package[2] with launchers for a number of programs. Each launcher automatically downloads the program the first time it is run, using Zero Install[3]. Zero Install is also used to fetch any required libraries and to check for updates, etc.
I made a launcher for Tgif without any trouble[4], but Inkscape is proving more difficult. The binary RPM on your site seems to use hard-coded paths to get the icons. I looked at the source code to see about fixing it, and I notice that you're already using autopackage's excellent binreloc tool. But, it appears that the RPM was compiled with this turned off!
I tried replacing the bin/inkscape file in the RPM with the one from the autopackage and it then worked fine. However, Zero Install can't extract from autopackages because they are implemented as 'executable archives' - extracting them requires running code inside them. This is OK for a program installed on a single-user machine, but Zero Install needs to support multi-user systems where the admin must be able to install a package without having to execute any of its code.
[ Aside: The goal of Zero Install is to make installing software system-wide so 'safe' (for the admin) that the admin can actually be replaced by a SetUID script, letting users share software installs automatically without needing an admin and without requiring them to trust each other. This combines ease-of-use and security, rather than trading them off against each other as in most other systems. ]
Would it be possible for you to build your binary RPMs with binreloc enabled, so that we can use them? Or, if you could host the "payload.tar.bz2" file from inside the autopackage then that would work too. Actually making Inkscape available is then extremely easy - I'll just create a short XML file giving the available versions, download locations and dependencies, as with the current Tgif XML file[4]. These XML files can be used by ROX (and Xfce) users by simply dragging the link from a web-page to the desktop's installer. They can also be run from the command-line using the '0launch' or '0alias' commands.
Thanks,
[1] http://rox.sourceforge.net [2] http://rox.sourceforge.net/desktop/ROX-All [3] http://0install.net/ [4] http://0install.net/tests/Tgif.xml
Hello,
On Sunday 14 May 2006 14:32, Thomas Leonard wrote:
I made a launcher for Tgif without any trouble[4], but Inkscape is proving more difficult. The binary RPM on your site seems to use hard-coded paths to get the icons. I looked at the source code to see about fixing it, and I notice that you're already using autopackage's excellent binreloc tool. But, it appears that the RPM was compiled with this turned off!
If you're talking about the static RPM on SourceForge I'm the one responsible for it. But I'm afraid anything too technical is beyond my capabilities. RPM creation sometimes verges on black magic. (At least to me.) However, I'll see into that binreloc business.
Or, if you could host the "payload.tar.bz2" file from inside the autopackage then that would work too.
I can't speak for the autopackage maintainer/s, but he/they surely appear to be highly more knowledgeable than me. So this might be a better solution if it works equally well for you.
Cheers, JFL
On Sun, 14 May 2006 17:52:28 +0200, Jean-François Lemaire wrote:
Hello,
On Sunday 14 May 2006 14:32, Thomas Leonard wrote:
I made a launcher for Tgif without any trouble[4], but Inkscape is proving more difficult. The binary RPM on your site seems to use hard-coded paths to get the icons. I looked at the source code to see about fixing it, and I notice that you're already using autopackage's excellent binreloc tool. But, it appears that the RPM was compiled with this turned off!
If you're talking about the static RPM on SourceForge I'm the one responsible for it. But I'm afraid anything too technical is beyond my capabilities. RPM creation sometimes verges on black magic. (At least to me.) However, I'll see into that binreloc business.
Yep, that's the one. Investigating further, I think you just need to use:
./configure --enable-binreloc
I'm curious about why this isn't the default, though.
Thanks!
On Sunday 14 May 2006 19:24, Thomas Leonard wrote:
On Sun, 14 May 2006 17:52:28 +0200, Jean-François Lemaire wrote:
On Sunday 14 May 2006 14:32, Thomas Leonard wrote:
The binary RPM on your site seems to use hard-coded paths to get the icons. I looked at the source code to see about fixing it, and I notice that you're already using autopackage's excellent binreloc tool. But, it appears that the RPM was compiled with this turned off!
I'll see into that binreloc business.
I think you just need to use:
./configure --enable-binreloc
I'm curious about why this isn't the default, though.
That I can't answer. I just build the RPM from the specfile provided in the source package. I have never changed the configure script. I'll try what you suggest.
Cheers, JFL
You wrote
Yep, that's the one. Investigating further, I think you just need to use:
./configure --enable-binreloc
I'm curious about why this isn't the default, though.
Could you please put that into a bug report in the tracker? There appear to be major problems with list mails atm, also to the autopackage maintainer.
ralf
On Sun, 14 May 2006 20:14:50 +0200, Ralf Stephan wrote:
You wrote
Yep, that's the one. Investigating further, I think you just need to use:
./configure --enable-binreloc
I'm curious about why this isn't the default, though.
Could you please put that into a bug report in the tracker?
Sure, I've added it here:
http://sourceforge.net/tracker/index.php?func=detail&aid=1488446&gro...
There appear to be major problems with list mails atm,
My original post still doesn't appear in gmane, only Jean-François's reply! I've copied the original message into the bug report in case anyone else can't see it.
also to the autopackage maintainer.
CC'd. Mike, is using --enable-binreloc to build the binary RPM sensible? I found this post from 2004 about it:
http://permalink.gmane.org/gmane.comp.autopackage.devel/677
It doesn't look like there would be a problem building the RPM with this turned on.
Cheers,
On Sun, 14 May 2006 21:26:10 +0100, Thomas Leonard wrote:
CC'd. Mike, is using --enable-binreloc to build the binary RPM sensible? I found this post from 2004 about it:
Hmm I never got this mail! I'm not sure what's going on here, is email not getting through to me without me realising?
http://permalink.gmane.org/gmane.comp.autopackage.devel/677
It doesn't look like there would be a problem building the RPM with this turned on.
Should be fine. A replacement for binreloc is being designed that won't require modification of source code in future however so --enable-binreloc may disappear at some point.
thanks -mike
On Mon, 15 May 2006 14:09:06 +0100, Mike Hearn wrote:
On Sun, 14 May 2006 21:26:10 +0100, Thomas Leonard wrote:
CC'd. Mike, is using --enable-binreloc to build the binary RPM sensible? I found this post from 2004 about it:
Hmm I never got this mail! I'm not sure what's going on here, is email not getting through to me without me realising?
Sending with my newsreader failed because it was pointing at the wrong smtp server, but I got an error and resent it immediately via gmail (to your @navi.cx address). So, I don't know why you didn't get it.
http://permalink.gmane.org/gmane.comp.autopackage.devel/677
It doesn't look like there would be a problem building the RPM with this turned on.
Should be fine. A replacement for binreloc is being designed that won't require modification of source code in future however so --enable-binreloc may disappear at some point.
OK, thanks.
By the way, now that autopackage has reached 1.0, are there any plans to stabilise the file-format? I'd like to get Zero Install to be able to run programs using them (as it already does for tar.gz, tar.bz2, zip, rpm and deb archives), but the headers of autopackage scripts contain this warning:
# Do not attempt to parse any information below this line # programmatically. The only supported interfaces this file exports # are the comments above (which may be in any order) and the command # line switches.
This is a shame, because the payload of an autopackage would often make an ideal Zero Install package too!
Thanks,
On Tue, 16 May 2006 18:21:04 +0100, Thomas Leonard wrote:
Sending with my newsreader failed because it was pointing at the wrong smtp server, but I got an error and resent it immediately via gmail (to your @navi.cx address). So, I don't know why you didn't get it.
Ah, that'd be why, I don't use that address anymore, it's changed (for various reasons) to mike@...869...
By the way, now that autopackage has reached 1.0, are there any plans to stabilise the file-format?
Sorry, no.
This is a shame, because the payload of an autopackage would often make an ideal Zero Install package too!
However the -x command line argument is guaranteed to be present in future versions, so you can simply run the file with that option to make it dump its contents to a new directory. You need the support code available to do that however.
thanks -mike
On Wed, 17 May 2006 15:54:38 +0100, Mike Hearn wrote:
However the -x command line argument is guaranteed to be present in future versions
Though thinking about it, this doesn't help much for the automated-conversion case as the payload can have any layout, and indeed the binaries inside aren't even guaranteed to be valid for the target system (consider C++ dual compiling for instance). If you want to reuse the binaries it's probably best to just build them in the same way we do, using apbuild.
thanks -mike
On Wed, 17 May 2006 15:54:38 +0100, Mike Hearn wrote:
On Tue, 16 May 2006 18:21:04 +0100, Thomas Leonard wrote:
[...]
By the way, now that autopackage has reached 1.0, are there any plans to stabilise the file-format?
Sorry, no.
This is a shame, because the payload of an autopackage would often make an ideal Zero Install package too!
However the -x command line argument is guaranteed to be present in future versions, so you can simply run the file with that option to make it dump its contents to a new directory.
Yes, but executing code from the downloaded package during installation would break our security model, which is that installation and uninstallation are safe (but execution is at your own risk ;-) We need to be able to extract the payload without having to trust the package.
There are several reasons for wanting this, including:
- We store the digest of the extracted tree, not of the compressed archive. This allows multiple methods of getting it (download an archive, download individual files, rsync or patch from previous version, etc) and lets us verify the installation later. This means that we don't know that an archive should be trusted until *after* we have extracted it (that said, it would be possible to store a second checksum for each version to cope with this).
- A system administrator should be able to install software requested by a large number of users without risking the whole system to every package. If Mary and Bob want to install some weird analysis program for their work, it shouldn't get the chance to wipe my data too. In the limit, the installation part of a sysadmin's job can then be done automatically by a setuid script.
- If I just want to read the documentation for a program, diff it against a previous version or just look at the code, I should be able to install the package without running anything (either because I'm worried about security, or just because I want to be sure it won't change anything).
- It should be possible to install documentation packages, clip-art and translations without letting the author run any code on my machine.
- Indexing and archiving systems should be able to index archives from the web without having to trust all of them.
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?
Anyway, it sounds like going with the RPM + binreloc will be a better solution for us.
Thanks,
On Wed, 17 May 2006 19:15:10 +0100, Thomas Leonard wrote:
Yes, but executing code from the downloaded package during installation would break our security model, which is that installation and uninstallation are safe (but execution is at your own risk ;-) We need to be able to extract the payload without having to trust the package.
Hmm well being able to install without root is actually possible with autopackage anyway ... being able to confine it so it installs to /usr without needing root access is a problem to solve some other day (all existing systems except for us crazy alternatives people need root :)
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.
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).
thanks -mike
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...
On Tuesday 23 May 2006 21:41, Thomas Leonard wrote:
I guess it makes sense to build the static Inkscape RPM with apbuild, since it's supposed to be as portable as possible...
I did try apbuild for the latest Inkscape release but it didn't work first time and I hadn't much time to investigate the matter further. I'll see what I can do for the upcoming release.
JFL
On Sunday 14 May 2006 22:26, Thomas Leonard wrote:
CC'd. Mike, is using --enable-binreloc to build the binary RPM sensible? I found this post from 2004 about it:
http://permalink.gmane.org/gmane.comp.autopackage.devel/677
It doesn't look like there would be a problem building the RPM with this turned on.
I've just taken a look at the source package but I don't find where to set the option. There is no configure.in file. Any ideas?
Cheers, JFL
On Wed, 17 May 2006 18:48:01 +0200, Jean-François Lemaire wrote:
On Sunday 14 May 2006 22:26, Thomas Leonard wrote:
CC'd. Mike, is using --enable-binreloc to build the binary RPM sensible? I found this post from 2004 about it:
http://permalink.gmane.org/gmane.comp.autopackage.devel/677
It doesn't look like there would be a problem building the RPM with this turned on.
I've just taken a look at the source package but I don't find where to set the option. There is no configure.in file. Any ideas?
Try the .spec file. I'm on a Debian system so I can't check, but you probably want something like this (not sure which path is taken so I added it to both!):
if [ ! -x configure ]; then CFLAGS="$MYCFLAGS" ./autogen.sh $MYARCH_FLAGS --prefix=%{_prefix} --localstatedir=%{_localstatedir} --sysconfdir=%{_sysconfdir} --enable-binreloc else %configure --enable-binreloc fi
HTH,
On Wednesday 17 May 2006 20:34, Thomas Leonard wrote:
On Wed, 17 May 2006 18:48:01 +0200, Jean-François Lemaire wrote:
On Sunday 14 May 2006 22:26, Thomas Leonard wrote:
CC'd. Mike, is using --enable-binreloc to build the binary RPM sensible? I found this post from 2004 about it:
It doesn't look like there would be a problem building the RPM with this turned on.
I've just taken a look at the source package but I don't find where to set the option. There is no configure.in file. Any ideas?
Try the .spec file. I'm on a Debian system so I can't check, but you probably want something like this (not sure which path is taken so I added it to both!):
if [ ! -x configure ]; then CFLAGS="$MYCFLAGS" ./autogen.sh $MYARCH_FLAGS --prefix=%{_prefix} --localstatedir=%{_localstatedir} --sysconfdir=%{_sysconfdir} --enable-binreloc else %configure --enable-binreloc fi
Thanks, I just did and it seems to be working, but then Inkscape doesn't run with a Pango error! Certainly not related to binreloc. So I'll need some time to investigate what's wrong. It's been a while since I last statically built Inkscape.
Cheers, JFL
participants (4)
-
Jean-François Lemaire -
Mike Hearn -
Ralf Stephan -
Thomas Leonard