On Saturday 15 October 2005 14:48, Mike Hearn wrote:

On Sat, 15 Oct 2005 12:42:53 +0200, Jean-Francois Lemaire wrote:

The autopackage apbuild tool has code which automatically strips these out, but it seems you are not using any equivalent. I would suggest building Inkscape against GTK+ 2.4 and this libpangocairo dependency will disappear.

OK. I will correct this.

But seriously, this is getting silly, we *already* provide binaries that have been tested and found to work on many distributions which statically link the more exotic dependencies .... why are we going through all this again?

There were no static RPMs for 0.42.2 and no volunteer for creating them for the next release. Bulya asked for a volunteer and I stepped up. Any mistake in the static RPMs creation is mine and only the result of my inexperience.

Sorry for any inconvenience.

On Sat, 15 Oct 2005 08:47:09 -0500, aaron-XW8b5UTxoeLYtjvyW6yDsg wrote:

Don't be to hard on yourself. We really need the manpower and appreciate your work. And I've been screwing up the autopackages fror a few releases now, so you aren't alone. ;)

Yeah, Linux in general makes this process a lot less intuitive than it should be.

Jean-Francois, perhaps a good way forward would be to use the same binaries inside both the autopackage and the static RPMs. That way, you can benefit from the tools we've written to automatically detect and correct such problems yet people who want an RPM and nothing else are still happy. It means you and Aaron can share the workload also, freeing up more time for actual Inkscape hacking.

I expect Aaron would be happy to send you a pre-made tarball of the RPMs, or alternatively you can just run the autopackage with the -x switch to extract the contents. These can then be turned into an RPM.

thanks -mike

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

Jean-Francois Lemaire wrote:

On Saturday 15 October 2005 03:04, DJA wrote:

...

If there are library or environment requirements for the Inkscape package, then those requirements should be listed on the download (or some conspicuous) page on the Web site, preferably with links pointing to wherever contemporary versions of those files/packages can be found.

Valid points, even though this more or less defeats the whole point of having static RPMs in the first place.

No, requiring additional libraries be installed by the user defeats the whole point of a statically compiled application. Static /by definition/ means that all necessary libraries needed to run the application are compiled into the binary and present after install. Naturally, a static RPM would reflect this.

If the intention is that all necessary libraries *not* be included in the package (RPM or source tarball), then the package is not static and should not be listed as such. Non-static is both acceptable and common.

Bottom line is, all I as a /potential/ user want to know is

1) What files do I need to install to get the app running, and 2) Where are those files.

If either of those needs are not met, I (the user) am likely as not going to ignore your application and look for something else [1]. If I can't install it, or the barrier to installation is too high, I can't use it.

Anyway, I'm creating the so-called static RPMs by following these instructions:

http://wiki.inkscape.org/cgi-bin/wiki.pl?CompilingStatic

Now, since there seems to be some issues with the way things are, maybe I should try adding some not-too-standard-libraries and ask the list what the devs think about it.

Again, it's not really so much about what libraries are or are not included in the RPM. I'm even fine with compiling from a tarball and installing it with Checkinstall. But even given a tarball and compiling it myself, I still need to know about dependencies. Not only what but where. If some obscure version of a garbage collector is required, then it's gonna be pretty hard to compile the app if I don't know exactly what version and where to get the required garbage collector.

From my perspective, this is a two-fold problem.

The first problem is that the RPM's are listed as being static and they aren't. That's solved by removing the static claim from the Website, thereby mitigating any misunderstandings on the part of the downloaders.

The second problem is a lack of a complete "System Requirements" statement specifying what is needed for Inkscape to run after installation of the program proper (whether from RPM or compiled tarball).

As can be seen, the solution to both problems is simply an update to the Website.

However, don't think I won't be grateful if you do produce a truly static RPM. I do appreciate your efforts.

***

[1] I'm talking about "I" as representative of the user community. That is, the class of users who are not developers. For myself, I will spend an above average amount of time getting trying to get something to work - I take it as a challenge ("stoopid computer is not going to beat _me_).