[LAU] How to package applications for the outside world

[James Cameron]

On Tue, Oct 27, 2009 at 07:36:30AM +0100, peter clarke wrote:
> I have built a little audio-related application - it's a vocabulary
> trainer for people learning a foreign language.  I am thinking about
> making it publicly available, maybe through sourceforge or similar...
> but I don't know how to go about packaging it into an rpm or Debian
> package for the end user.  It's a python script with various data
> files and dependencies such as ecasound.

Install the Debian package python-setuptools if you are using Python
below 2.4.

Make sure you have created a setup.py in the usual Python fashion, then
you can just;

	python setup.py bdist_rpm

And an .rpm file should be generated.

You can convert it to .deb with alien, if you must.

Look at "python setup.py --help" for more interesting stuff, and check
the Python documentation for tricks you can play with setup.py.

> Any tips on learning how to build packages?  Thanks for any advice you
> can give.

It varies by packaging style.

Briefly, rpm --build is run against a .spec file that you prepare, and
rpm sucks in the .tar.gz, any patches you give it, and generates an rpm.
Usually all in separate, strange, isolated directories.

For Debian style, you create a directory in your source tree, it
contains a few files like control and rules, and the rules file is to
compile and install the package into an alternate DESTDIR.  Then you use
dpkg-buildpackage to generate the .deb.

I prefer Debian packaging, because of the good dependency resolution.

On Tue, Oct 27, 2009 at 03:04:30PM +0800, Ray Rashif wrote:
> I honestly think upstream developers shouldn't bother themselves -
> it's what distros are for. You should just put up one source tarball
> and a binary tarball (with runtime dependencies _documented_, not
> included, which someone can download and run from within the
> directory).

It isn't enough, especially for niche software.  Distribution teams just
have too much to do to package the small stuff.  I've learned this from
experience with Netrek and PPTP.  Upstream sometimes really should do
something, even if it is to provide slightly incompatible packages that
generate noise from users that cause distribution teams to take notice.

Every little bit helps, and if you are trying to "sell" your open source
software, you may have to take on the role of distributor as well.

-- 
James Cameron
http://quozl.linux.org.au/