[m-dev.] Re: mercury: should this package be removed?

[Peter Moulder]

On Wed, Feb 20, 2008 at 09:50:44AM +1100, Paul Bone wrote:

> And since I haven't packaged for Debian before this is rather an
> ominous task.

Here are some suggestions.  It's been a while since I've created Debian
packages, so trust the Debian New Maintainers' Guide over me.


The usual way of creating a Debian package is with the dh_make program
(in the dh-make package).  Create (unpack or copy) the source tree that you
want dh_make to modify, cd into it, then run dh_make.

When it asks you

  Type of package: single binary, multiple binary, library, kernel
  module or cdbs?
  [s/m/l/k/b]

I suggest selecting (l)ibrary; then, to show how it would have differed
if you'd selected (m)ultiple binary, either do
  diff -duwr /usr/share/debhelper/dh_make/debian[lm] | less
(note that #ALLCAPS# in the diffs indicates a placeholder that debhelper
fills in) or run dh_make again in a separate copy if you want to see how
debhelper fills in those placeholders.

The file debian/foo.install indicates the files that should go in binary
package foo.  If a debian/install file is present, it behaves like
debian/SOURCEPACKAGE.install.  man dh_install for details.

(Incidentally, the debhelper documentation recommends dh_install over
 dh_movefiles, but doesn't say how it's better.  dh_movefiles has the
 property of moving files from debian/tmp rather than copying files,
 which makes it easier to check for files you haven't assigned to any
 binary package or files you've included in multiple binary packages.
 I suppose you could do the same with find/sort/comm, but I often prefer
 dh_movefiles.  Note that dh_movefiles uses debian/foo.files while
 dh_install (usually) uses debian/foo.install.)


Once you're happy with the resulting tree, first make a copy of this
tree (e.g. to protect your work, and to help checking that the ‘clean’
target returns the tree to its pristine state), and then do:

  ./debian/rules build && fakeroot ./debian/rules binary

(The ‘... &&’ part is optional, but I habitually include it, just to
 check for bugs that involve doing root-requiring steps as part of the
 build target.)

It should create some .deb files in the parent directory.

Then check those .deb files.  For a sanity check, do
‘dpkg --contents ../foo.deb’, and check that it has roughly the right
files (and in particular that it's not empty or missing a whole
directory).

Then try ‘lintian -Ii ../*.deb’.  A related (newer) package is linda,
which I haven't used before.


One thing to take care of that you might not think of is handling the
caveat mentioned in mercury's INSTALL file:

  # Step 3.  Run `make install'.
  #          This step will also take a long time.
  #
  #	BEWARE: if something goes wrong in this step, e.g. running
  #	out of disk space, and the installation has already gotten
  #	past installing the documentation, and started installing
  #	the different grades of the libraries then in general it is
  #	NOT sufficient to simply rerun `make install'.  Instead you
  #	may need to start from scratch again.

Does ‘start from scratch again’ require doing ‘make clean’, or does it
suffice to re-run make?  If the latter, then I think this can be
achieved by having debian/rules' install target start by removing the
build-stamp file.

Whereas if a ‘make clean’ is required, then I can't think how to handle
this exactly right.  Having the build (or build-stamp) target start with
‘make clean’ almost works, except that it will presumably fail if the
install (or binary etc.) target is run as real root instead of under
fakeroot (and the build target is run as non-root).  Having
debian/rules' install target do ‘...  || { rc=$?; make clean; exit $rc;
} will usually work, but may be brittle, and may be rather surprising to
a user trying to debug a compile failure.  (Having ‘make clean’ in the
build target has the same problem to a lesser extent.)  OTOH, I believe
Mercury's install target more or less does ‘make clean’ at the start of
each grade anyway.

Maybe the best thing if ‘make clean’ is required is to ignore this
problem except to document it as an upstream bug.


Another non-obvious thing to check is to make sure that either mercury
allows being compiled & installed with ‘make -j3’, or that the recursive
make is never parallel.  E.g. (for the latter) make sure that
debian/rules ignores parallel=n option in DEB_BUILD_OPTIONS (and instead
documents that it's deliberately ignored).


HTH,

pjrm.

--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at csse.unimelb.edu.au
Administrative Queries: owner-mercury-developers at csse.unimelb.edu.au
Subscriptions:          mercury-developers-request at csse.unimelb.edu.au
--------------------------------------------------------------------------