On Sat, Aug 27, 2005 at 07:23:35PM -0300, bulia byak wrote:
Yes, I spoke to him about RPMs after the last release. He said he will no longer do static RPMs. I think he feels that they cause more problems than they solve. I don't completely agree, but I see his point.
I'm out of my depth here, but my impression was that they worked relatively well. I think even autopackage had more bugs reported than static rpms.
My issue is that I have no way to trouble-shoot the static RPMs. (And it's very time-consuming to build the static libraries.) I'm building them for an RPM-based system on my Debian Unstable box, which seems rather wonky to begin with. I can't even _install_ what I build to test it. :P And now with my recent change to/back from Ubuntu, I really don't trust my system at all. It has some pretty strange behaviors, which I think are due to various library versions being installed.
What I'd like to see is people building distro-specific RPMs. We include a spec file in the tar.gz file, so it's insanely easy to do. If someone plans to run Inkscape on their distro, it's just a matter of doing:
rpmbuild -ta inkscape-VER.tar.gz
And then they can upload the resulting RPM. I think this makes much more sense than the static RPM, which gets people's hopes up and then they run into weird GTK version issues. If libgc is an issue, maybe we can help out that project by trying to get them to include a spec file in their tar.gz too.
Also, there are many fewer downloads of the static RPMs compared to the autopackage bundle. I'd rather urge people to use autopackage, since it's got willing maintainers, a scripted build system, etc.
I know the static RPM has been useful in the past, but I really want to spend my time on Inkscape doing other stuff. :)