On Sat, 15 Oct 2005 20:48:50 +0200, Jean-Francois Lemaire wrote:
I may be wrong, and wouldn't want what I'm about to say to be construed as impolite, but I'm not a strong believer in the autopackage concept. I prefer the "system-wide package manager" approach. And judging by the download figures, I'm not the only one preferring RPMs to autopackages.
Really? Here are the download figures for the last two releases:
0.42.2 static RPM - 91 i386 downloads, 106 i686 downloads autopackage - 1980 downloads
0.42 static RPM - 394 i386 downloads, 536 i686 downloads autopackage - 2983 downloads
In other words they're about 3x as popular for the 0.42 release, or over 10x as popular for the 0.42.2 release.
All of this is of course dwarfed by Win32 and MacOS X download activity.
Anyway, regardless of what is theoretically cleaner, we live in a world in which Linux distributions are fragmented and not 100% compatible, usually pointlessly. The static RPM is being advertised whether you realise it or not as a one-click install for end users who don't want to worry about dependencies, that will work on any RPM distribution. If you don't want to provide that guarantee, then make distro/version tied RPMs that you know will work.
Actually, I'd argue that having a clean split between system level code and third party code is a good idea. Look at how mobile phones are remaining basically impervious to viruses and spyware, by utilising a very strong security model oriented around preventing applications intermingling with the operating system.
You know, if all there is to make the static RPMs more widely installable is adding a few libraries, then so be it
That is not all it requires. Binary portability on Linux is a large and complex issue, refer here for more information:
http://autopackage.org/docs/devguide/ch07.html
(and that doesn't cover everything)
If you are going to try and produce an RPM that works on any distribution, even if you restrict yourself to the subset that use RPM, then you will have to learn about this stuff. Or you can reuse the work we've put into binary compatibility and recycle the autopackage binaries.
- Either I create the static RPMs on my rather bleeding-edge distro and
add statically every library that is not available on other not-so-bleeding-edge distros. This is rather straightforward;
.... however mostly useless for the non-developer target audience
- Or I try to figure out how the hell I'm supposed to run rpmbuild against
GTK+ 2.4.x when 2.8.x is installed on my system. I suppose it must be possible.
.... if it isn't then perhaps rpmbuild is the wrong tool for the job.
Alternatively, use apbuild which with a recent toolchain will automatically strip bogus dependencies like libpangocairo.
The way I see things is that the static RPMs are created rather as a short-term and convenient solution for people using Linux distributions which do not provide Inkscape or a recent version of it or an easy way of upgrading it.
Well this was one of the motivations for building autopackage. If you believe it's somehow wrong for software to be installed yet not registered with the RPM database, we'd welcome patches to add native package manager integration (NPMI). That way we can fix the underlying problem here instead of duplicating work.
thanks -mike