People who use your software generally don't need the hassle of compiling and installing it. What works on your machine might not work on theirs, for various reasons that you might not have thought of. You can overcome this and make your users' lives easier by distributing pre-compiled binaries. I've done this in two ways and found it pretty straightforward with great benefits to my codes.
Advantages of packaging
Things that are good about packaging your software and distributing it via package managements systems include:
- Makes it easy for people to get your code
- Your code gets built on multiple platforms, exposing possible problems efficiently
- It gets built in a clean and consistent build environment, again exposing possible problems efficiently
- Complying with quality requirements of distributions results in better code
Packaging for Ubuntu
I started off packaging my codes by creating a Personal Package Archive (PPA) at launchpad.net. There are many good guides to creating packages, and some of the ones I referred to are:
But what I found was that I kept getting errors which I did not understand. So here I will try to list some of those and how I solved them.
Common problems - building
The first thing to do before uploading a package to a PPA is to build it locally.
debuild automates the build process;
pdebuild additionally sets up a clean build environment. Read about that here. Some sources of problems at the build stage include:
- Badly written Makefile - the automated build system calls the standard rules which should be in your makefile -
cleanto remove any previously built code and leave the directory identical to when the source code was unpacked,
allwhich will build everything that needs to be built, and
installwhich will put all the files in the standard directories. If any of the rules don't work, the build process will fail.
- Incorrect dependencies -
controldefines the dependencies which are required for the build process.
gfortranneeds to be given as an explicit build dependency for fortran codes. Failure to specify the dependencies properly caused most of my early build failures
- Unrepresentable file changes. The package must be built from a pristine tar file containing the unaltered source of the program. Any changes that you need to make to the code to package it must be made in the form of patches and not directly to the code. If you change the code and then try to build the package, it will not succeed.
- Symbols files - packages containing a shared library need to contain a symbols file. If you try and generate it yourself using dpkg-gensymbols, the build will almost certainly fail, arbitrarily and inexplicably. There is, as far as I can tell, no logic behind these failures. The thing to do is to add
pkg-kde-toolsto the build dependencies, and in the
rulesinvoke the tool's symbols helper with the following, containing the necessary library name and version number:
%: dh $@ --with pkgkde_symbolshelper override_dh_makeshlibs: dh_makeshlibs -V 'libxxx1 (>=x.x.x)'
Common problems - uploading
Once the package has been built you can upload it to the PPA with
dput. Possible causes of failure here include:
- A bad version number - if you are trying to upload a package with the same or lower version number than something already in the repository, it won't work.
- Problem with the pristine tar file - if you upload a pristine tar file which differs from one already uploaded with the same version number, Launchpad will reject the package.
Packaging for Debian
Packages in the main Ubuntu repositories are cloned from Debian, the distribution on which Ubuntu is based. Other distributions also clone the Debian repositories, so getting a package accepted into Debian is a good way to make it widely available. Doing this requires the following:
- The package must consist entirely of freely licensed code, as described in the Debian social contract
- It needs a sponsor - someone to check that the package conforms with Debian policy and to upload it to the Debian archive
A message to the Debian Astro mailing list is a good way to seek sponsorship for astronomy packages.