[Developers] I might be interested in creating a debian package!

[Barak A. Pearlmutter]

I'm a Debian developer, and I've started packaging admb.
Would very much welcome patches suggestions help etc.
When (if) it is whipped into shape it would be my pleasure to upload
it into Debian.

> The debian package build process would need to be completely
> automated in order for the ADMB project maintainers to keep it
> current. Usually, this automation is accomplished using make.

The way this typically works is that the Debian packaging information
per-se goes into a debian/ subdirectory maintained by the Debian
project.  Changes outside there are kept minimal: bug fixed, generally
send to and coordinated with the upstream developers, and changes to
make the package build and install in a Debian-friendly way across as
many architectures as possible.


You can see what I've done so far, quite minimal just a quick pass,
via:

 git clone git://git.debian.org/git/collab-maint/admb.git

The main pending issues are

(a) The need to do something special on 64-bit architectures to ask
    the build system to not use -m32, which I hacked around in an ugly
    way on amd64 only; I have no idea how this will work on other
    64-bit architectures.

(b) The GNUMakefile generated by ./configure does not use the standard
    API.  In particular, "make install" does not pay attention to
    DESTDIR, and prefix is hardwired at ./configure time rather than
    just having a default set, and even at ./configure time particular
    system target directories are not set using the standard names, in
    particular it is hard to get /usr/bin to hold only user-callable
    things, /usr/lib/admb to hold architecture-specific things,
    /usr/share/amdb to hold non-arch-specific things, and
    /usr/share/doc/amdb to hold all documentation.  As is, /usr/bin/
    would end up containing, e.g., all sorts of non-executables, like
    sed script fragments and such.

(c) Although this could be hacked around with shell scripts wrappers,
    ideally the executables would have a default value to ADMB_HOME
    (or really its relevant components) which are used if that env
    variable is not set, and those defaults would be set by passing
    things constructed in the makefiles out of prefix & friends using
    CPPFLAGS+=-MADMB_HOME_DEFAULT=\"$(prefix)...\" Icky I know.

(d) It seems like generating shared (i.e., dynamic) libraries would be
    a good idea.  Is there some reason that would be a bad idea?

(e) Man pages, even if they are short stubs...

(f) There are things happening at build time, like invoking
    svnversion, that (1) might not be very robust, like if the build
    is not in an SVN repo as in my case, and (2) require build-time
    dependencies that will cause a lot of work for the debian
    autobuilders.  It would be good to have all "true" build-time
    dependencies documented in, eg, README.txt.  lex?  flex?

I'm torn between doing something ad-hoc vs rejiggering the build
system to more fully integrate autotools and maybe automake.  And
working around some of the above.  Trying to rejigger the build to
generate dynamic libraries.  A bit more than I'd bargained for!

					Cheers,

					--Barak.
--
Prof Barak A. Pearlmutter
 Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
 http://www.bcl.hamilton.ie/~barak/