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

[aaron]

A draft of a man page.
Hope this helps in a small way.
Aaron


On 02/06/2011 03:59 PM, Barak A. Pearlmutter wrote:
> 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/
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: man.pdf
Type: application/pdf
Size: 5502 bytes
Desc: not available
URL: <http://lists.admb-project.org/pipermail/developers/attachments/20110207/e3f50ff8/attachment.pdf>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: man.1
URL: <http://lists.admb-project.org/pipermail/developers/attachments/20110207/e3f50ff8/attachment.ksh>