Unified all-in-one packages for end users


#1

Hi everyone!

Looking at the package wide variety of packages at synfig.org/Download, watching all the problems with updating packages to new distributive releases, building my own packages for Fedora 7 and 10, I finally asked myself “Is this a right way to go?”

Everytime I build a package of new (svn) version of synfig I need to build it 4 times - in Fedora 7 i386, Fedora 7 x86_64, Fedora 10 i386 and finally Fedora 10 x86_64! There is a lot packages at the Download page and still most newcomers forced to build synfig from sources.

The answer looks simple - let the distribution vendors to produce packages. But currently we aren’t supported by them that much (Fedora refuses to include synfig in their repositories, Ubuntu lags with updates).

Other problem: I want to provide users a way to easily install some particular version of synfig. Yes, yes, easy. Without connecting additional (unofficial) repositories, without fiddling with dependencies. Just click-and-install. That’s a critical point for driving collaborative project - provide solid environment. I personally don’t want to depend on linux distributions packages - they use stable versions and don’t update as often as we. Oppositely we update relatively often to test new features and recieve benefits from recently fixed bugs.

That’s why I made an attempt to develop some kind of ‘unified’ package. Such package should comply following requirements:

  • Distribution-independence (rpm-package should be suitable for any modern rpm-based distro, same for deb-package)
  • All in single package (installation with one click, synfig and synfigstudio included)
  • End-user orientation (no devel stuff)
  • Minimum dependencies (only rely on components which most systems have installed already)

That’s what I’ve got:

Packages for Debian-based distributives:

Packages for rpm-based distributives:

I need help in testing those packages. Please try to install those packages on your distribution and report issues you encounter.

I’ve tested them on Fedora and Ubuntu only:

  • i386 build tested on: Ubuntu 8.10 (i386), Fedora 7 (i386), Fedora 7 (x86_64), Fedora 10 (x86_64).
  • x86_64 build tested on: Ubuntu 7.04 (x86_64), Fedora 7 (x86_64), Fedora 10 (x86_64).

It will be nice if you make tests on those and other distros.
Cheers!


#2

I see only one problem: the architecture.
Also don’t rely on vendors packaging gives the additional problem of make the package available to all flavors of linux distributions. So the package gets like a minimum of the features (mainly the import and export ones). It is fine though, because exporting a png sequence is enough for most of the users.

Nothing to test here as well as I use Ubuntu 8.10 and it has been tested by you. Anyway, where does it install the binaries? in usr local, custom folder, usr/bin?. I ask that before try it becasue I don’t want to overwrite my last build. I use usr/local.

-G


#3

Yes, I building synfig package twice - x86_64 and i386. But that’s easier than to make separate build for each distribution version. And I have a build script: synfigstudio-build.sh.
And yes, It seems Ubuntu (x86_64) unable to run i386 deb package, only x86_64 (luck of i386-compatible libraries).

  • ffmpeg export should be available if ffmpeg installed
  • imagemagick export should work if it’s package installed too
  • openEXR, lavcodec and magick++ are disabled for now, but I could build with them later
  • all the rest should work
  • binaries are go to /usr/bin/
  • most shared data stored in /opt/synfig
  • some data (like .desktop file) is stored in /usr/share/… to provide desktop integration.
    It will be nice if you will find time to test package on your Ubuntu 8.10 installation, cause there is not enough proof if a package tested only by single person (me).

#4

Some things:

autopackage, 0install or another distro-independent package format should probably be used rather than deb/rpm.

For the libraries that are included in the package, you’ll need to track security issues for them and provide automatic updates.

Using /opt in combination with /usr isn’t really a good idea, best just use /opt. 0install/autopackage would solve this anyway.

The architecture thing; what about PowerPC users?


#5

0install requires 0client to install package - that’s additional dependency.
Synfig is not suitable for autopackage, cause its not relocatable. See autopackage.org/developer-quickstart.html

Ok, I’ll take that into account. For now - yep, USE AT YOUR OWN RISK.
No automatic updates. User install package just downloading and clicking on it. If newer package installed then it replaces older.

Yes, don’t like it too. But I don’t know how to make linux distribution handle *.desktop file located in /opt. We want SynfigStudio menu entry, aren’t we? :wink:
Other solution is to place synfig-related libs in /usr/lib/synfig and data to /usr/share. But not sure about that.

Have no Mac’s around. Is there any way to build ppc package on i386/x86_64 machine?


#6

Current research task is to figure out how many various distributions could install/run those packages. Ubuntu, Fedora, Debian, Mandriva, Suse, others?


#7

The synfigstudio_0.61.09-2316.morevnapackage.1_i386.deb one installed fine on my father’s computer. (running debian stable on a 32b arch)
But now all I have is a “Floating point exception” message when I try to start synfig or synfigstudio.
Well, I suppose I may have to install gdb or something like that too… :slight_smile:


#8

rore:
Thanks for report! Which version of Debian?


#9

i386 rpm package tested on Mandriva 2009.0 Free, i686, SMP, kernel-desktop 2.6.27.7
No problems with installation/running.


#10

Ubuntu 8.10 Intrepid Ibex
CPU: Intel® Core™2 Quad CPU Q9450 @ 2.66GHz
Kernel: 2.6.27-9-generic
GNOME: 2.24.1

Not previously installed the official package.
I have a compiled version of synfigstudio in usr/local/bin.

Installed your package (x86_64) using gdebi.It complained about there is an official package in the repository.
Running /usr/bin/synfigstudio goes well. I didn’t notice anything wrong.
-G


#11

One question: Are the builds optimized for speed? Which settings did you used? Thanks.
-G


#12

Genete: no optimizations. just

./configure --prefix=${PREFIX}/ --includedir=${PREFIX}/include --disable-static --enable-shared

See synfigstudio-build.sh.


#13

Hey what about windows? It needs a better build method.


#14

^^ Can’t argue with that! :wink:

Chris


#15

SVN2354 build.
ImageMagick++ render target support is now integrated into package.
Testers are welcome.

Packages for Debian-based distributives:

Packages for rpm-based distributives:


#16

For me it’s oldstable (etch)
The problem might be related to this : lists.alioth.debian.org/pipermai … 00095.html


#17

When attempting to install the new stable Synfig (well, upgrading actually) I get this error. Now, I can simply click “Ignore warning and install”, but hey, we need users to stop being too scared, aye?

Using Natty Narwhal - Ubuntu.

Here’s the pic: i.imgur.com/yeokm.png


#18

Good catch. We will try to fix it as soon as possible.
-G


#19

That’s a problem but it’s related to Ubuntu, i had this problem with several packages and my best choice was GDebi, is not installed as it used to be but is still available from repositories, the worst part is that updating Wine has come to be a problem too due to this thing about bad quality packages.


#20

Win7 throws a message, because it’s unsure that the package has installed correctly. But it has. I don’t know how to convince it otherwise, short of digitally signing it.
Maybe it’s time to update the NSIS installer package. :frowning:

Chris