That's a bit of a mouthful of a subject line, isn't it?
Let me introduce myself. I'm the maintainer of the autopackage project (http://autopackage.org/) which is focussed on making software installation on Linux as easy as it is on other platforms. There are several parts to that mission, but autopackage is one of the first - it's a way of building packages that can be installed on any distribution *with* dependency handling. The idea is that maintainers of applications and libraries build a binary package at the same time as releasing source code packages, so ensuring that end users need not compile from the source.
A few things that autopackage is: - A framework for building distro-neutral installers - A system that checks the OS directly for any dependencies required, so you don't have to use autopackage to install dependencies: it will detect their presence regardless of whether RPM, source code or simply copying binaries from another machine was used. - Currently experimental. We're about to release 0.4. All packages built until we release 1.0 are classed as experimental too. - Distributed: autopackage does not depend on having large repositories of packages built from it. The idea is that maintainers host packages themselves, and packages know where to go and find them to resolve dependencies.
A few things autopackage is not: - It's not a distro. The idea is not that we package everything - far from it, all the packages we produce currently (there are only a few) are for testing purposes only. - It's not a replacement for RPM. For version 0.6/0.7 we want to integrate support for using native RPMs/DEBs/ebuilds where they exist, and utilising the native dep resolver when possible.
Why is this relevant to Inkscape?
I noticed on your last status report that you were considering delaying the introduction of GTKmm because it was not widely spread enough amongst distros. This is problematic, as the reason it's not installed by default in most distros is the lack of popular apps using it. One of the reasons people are reluctant to use it, is the lack of distros which include it.
Clearly this is a catch-22 situation. So what is the answer?
autopackage 0.4, which features network dependency retrieval, is going to be released soon. After that comes 0.5, in which we don't really want to add new features but instead concentrate on packaging a reasonably complex real world application. Up until now we've been using Gaim, which works OK but the Gaim maintainers have been less than co-operative so we're scouting around for something else (which preferably uses language bindings) to package instead.
Programs that use language bindings are primary targets for us, because the dependency problems caused by them often discourage people from using them. This is not good, because language bindings have the potential to dramatically increase the productivity of free software developers by letting us get away from C. Therefore, I want people to use them, therefore I want people to depend on them.
I have a proposal:
If you go ahead with your original plans to make full use of GTKmm and all the useful things it provides, for 0.5 we will package Inkscape and GTKmm together in a distro-neutral fashion. You can link to these packages from your website, as well as providing packages in any other form you like. If up to date RPMs, DEBs etc are not available for the users distro, they can try the .package (autopackage) files. They will scan the system for GTKmm and other deps, and download and install them if not found.
Here is a quick attempt to address some questions I expect you have.
Q: But there are other reasons we are wary of GTKmm! A: Yes. The maintainer of GTKmm is not aware of any building problems on MacOS X however - being standard C++ and given that Apple use gcc, it's hard to imagine where potential problems might come from. Certainly, it would not be hard to port if there were issues. I'm not sure this is a valid reason to avoid GTKmm: if people want to use Inkscape on MacOS then any issues (if there are any) will be worked out. Murray Cumming can comment more on this. DLL bloat: all I can say here is that many, many win32 applications ship with MFC or ATL DLLs so this is hardly a problem unique to ported applications. Certainly the benefits of a good C++ wrapper outweigh the additional download size IMHO.
Q: Isn't Linux binary portability really bad? A: Well, yes and no. A part of the work we do for autopackage is R&D into Linux binary portability. You're almost certainly aware of the C++ ABI break, about which we can do nothing. Fortunately gcc 2.95 is several years old now and *all* modern distros are compiled with gcc 3.2, so this is not so problematic (though autopackage can detect and deal with it nonetheless). There are other issues, of course. We have some simple drop-in build tools to control glibc symbol versions, the package build program scans all ELF binaries to locate common mistakes, and so on.
In order to improve the binary portability between Linux distros, minor changes to the build system and/or source may be necessary. They should not affect the functionality of the program in any way.
Q: Where does Windows come into this? A: You want a Win32 port. As you have already discovered .....
http://sourceforge.net/tracker/index.php?func=detail&aid=841633&grou...
.... Win32 binaries are always binary relocatable, whereas Linux binaries often are not. Inkscape is typical in that it contains constructs of the form: open_file( INKSCAPE_GLADE_DIR "/foo.png" ) or whatever, ie the path to the binary is constructed at compile time, not runtime. In other words, it's source but not binary relocatable.
A minimum requirement of software packaged using autopackage is that it must be binary relocatable. There are several use cases for why this is good - from people who want to install to their home directory (autopackage allows them to do this automatically), to people who ran out of space on / and added a new harddisk, to admins installing to network mountpoints.
This is not so trivial on Linux because there is no equivalent to the Win32 GetModuleFileName() call. Fortunately, as part of developing autopackage we have written a simple C file that can be dropped into any program or library and used to determine the prefix at runtime. This file is Linux specific (it reads /proc) but it can be switched on/off automatically in the configure script. Ports to other platforms will be added as time goes by.
binreloc, as we call it, is really easy to use. It redefines the standard macros, so you can replace:
open( DATA_DIR "/foo.png" );
with
open( DATA_DIR("/foo.png") );
That's it! TLS slots are used to ensure there are no memory leaks.
You already need to remove hard-coded prefixes like that from the code for the Win32 port to be really robust. At the same time, it can be done for Linux. If you aren't wanting to do this straight away, I might be able to write a patch to do it using binreloc. I also hack on Wine (my other project) so hopefully making it work for Win32 as well wouldn't be too hard.
Q: But GTKmm is already packaged for Fedora and Debian. Users will want to use them, not the autopackage versions! A: Sure, we know that. At the moment autopackage can only fulfil missing dependencies using its own packages. In the 0.6/0.7 timeframe we want to add support for at minimum apt, and probably also yum and maybe urpmi so users will get the packages designed specifically for their distro instead of the generic ones.
Q: What about GTK 2.2 vs GTK 2.0? A: Yeah, maybe. We're kind of reluctant to package GTK itself as that's really the distributors job - GTK is a core OS component these days. Linux is moving so fast at the moment that to be able to use new software I think it's reasonable to expect people to be upgrading their distros. Supporting one previous version is probably OK, supporting a year old distro is pushing things a bit. Still, there's no theoretical reason why we can't build GTK autopackages if the demand is there. Most people would want to at least wait until we integrate better with RPM before upgrading their system like that.
If you have other questions about autopackage specifically, then see the autopackage FAQ:
http://www.autopackage.org/faq.html
In summary, my proposal is simple:
* You continue the original plan of using GTKmm and reap the productivity benefits. Murray is chatting to the fink guys, so hopefully MacOS X worries should soon be dealt with.
* We build Linux distro-neutral packages of Inkscape and GTKmm for the autopackage 0.5 milestone. We host them on our servers.
* You link to them from your website. This lets people who don't have GTKmm packages available natively for their distro install Inkscape binaries anyway.
* We maintain them until autopackage reaches version 1. At this point we don't want to maintain packages anymore, and will be pushing out all the specfiles we were testing with to the community and maintainers. At this point you can decide whether the test packages were popular enough to warrant continuing with autopackage.
Apologies for the overlong email, but I wanted you guys to have some context. What do you think?
thanks -mike