A few words of perspective on packaging. My experience has been that I
have packaged a few projects with autotools; I've helped others do the
same; I've created debs for Debian/Ubuntu, and RPMs for Fedora; I've
written ebuilds for Gentoo, and I've experimented with the Nix package
manager, which by it's nature pushes software building questions to the
forefront.
The really key things, as I see it, is your software should be designed
and wrapped in such a way that, when built from source: 1) binaries and
data files can be installed to /any/ weird directory/system
configuration, and still work correctly; 2) configuration of these
directory paths can be done easily and (bonus points) through a well
recognized interface; 3) the build process assumes as little as possible
about the target system in advance.
Why are these things important?: The biggest challenge, next to writing
the software, is getting all the distros to include it. Some of the
adhere to the FHS, but some don't (which I see as a good thing). Some
need to use special flags, some don't. Some are binary-based, some are
source based. Also, let's not forget (outside the distros) are the
people who want to install your software from source, to some special
locations, without having root privileges. All of these people want a
quick, easy, and straightforward way of customizing every aspect of
installation. In particular, the distro devs usually have specialized
script seems designed to automatically pass in said configuration
directly into popular build systems like autotools, cmake, cabal, etc.
If those distro devs realize they are going to have to write a
complicated patch to deal with your unique build/installation system,
they may just give up.
Some helpful tips:
A) Use a standard, well recognized build system. Autotools and cmake are
the two most popular. Some languages like Python and Haskell have their
own language builds system or configuration script systems which you can
use instead.
B) AVOID path hardcoding, which makes assumptions about where any files
are going to be located, even if such assumptions are promoted by the
FHS. For example, don't write code which assumes that configuration
files are going to be in /etc. Instead, your build system should define
a configuration variable pointing to the correct directory, which should
be used by your code at compile time or run time.
C) Don't precompile code or include static libs. (Unless, of course, for
your "generic" binary release. I mean, don't ship precompiled stuff in
the source code.) Avoid forcing the use of flags for compiling features
you think that people probably will want, but are not actually necessary.
D) If something is a dependency of your software, the build system
should test for it or recognize it in some way. One bad thing that
happens is that developers, and eventually distro developers, use
implicit dependencies: they build on a system that has program, library,
or kernel function XYZ, without realizing it is a dependency, and then a
year later a bunch of users start sending in bug reports because the
software breaks on their personal systems which lack said dependency.
Anyway, I just spilled that all out on the keyboard in about twenty
minutes, hopefully it is helpful. Don't have time to revise/proofread.
(Off to class!)
-- frigidcode.com
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
This archive was generated by hypermail 2.1.8 : Tue Feb 05 2013 - 07:47:18 AKST