maven-debian-helper: porting to dh(1)?

Steve Langasek vorlon at debian.org
Sun Jan 8 03:50:06 UTC 2012


Hi folks,

The wiki page at http://wiki.debian.org/Java/MavenBuilder mentions that
supporting dh(1) is on the todo list.  As getting rid of cdbs interests me,
I took a stab at implementing this.  The result is attached.

With this on the system, a maven-using package can have a dh(1) debian/rules
that looks like this (taken from activemq):

#!/usr/bin/make -f

%:
	dh $@ --buildsystem=maven

override_dh_auto_build:
	dh_auto_build -- install

override_dh_install:
	dh_install
	chmod 644 debian/activemq/etc/activemq/instances-available/main/log4j.properties
	chmod 644 debian/activemq/usr/share/doc/activemq/examples/conf/log4j.properties
	chmod 644 debian/activemq/usr/share/activemq/README.txt

get-orig-source:
	uscan --download-version $(DEB_UPSTREAM_VERSION) --force-download --rename


There are a few things that I feel are still moderately un-dh-like about
this system, however, and I wonder if anyone here has ideas about how to
improve it.

 - dh_auto_test isn't usable with this build system, because there is
   evidently no standard 'check' target.  Is there some way that the
   existence of a suitable target could be detected at build time?  (As a
   fallback, we could make dh_auto_test a no-op except when overridden and
   an extra argument has been passed for the target.)

 - Likewise, the only target supported by the build system is 'package', and
   if the build system uses another, this must be passed as an argument to
   dh_auto_build (see above).  Torsten assures me that 'package' is the
   standard target and everything else is non-standard, but in my
   unscientific examination of packages so far, 'install' seems to be a
   fairly common alternative.

 - Extending the classpath for maven is done using a DEB_JARS envvar.  This
   is rather un-dh; it also has weird semantics (inherited from the cdbs
   class) in that it takes jar names in various formats and tries to search
   the system for them.  At the very least, the variable name should
   probably be changed for dh; DEB_ as a prefix for variables defined within
   debian/rules is a cdbs-ism.  Would MAVEN_JARS be ok here?

 - The double invocation of classworlds.jar, once for the main package and
   once for the docs package, is a bit awkward, and feeds into some of the
   problems above.  For instance, since there's only one invocation of
   dh_auto_build, you can't easily specify extra/alternative arguments that
   you want to have passed for docs building but not for building of the
   main package.  (BTW, does anyone know why the CDBS rules pass
   -Ddebian.package when building docs, but not when building the main
   package?)

 - The build system has to know the names of the binary packages its
   building for.  This is certainly unusual, since dh_auto_build means
   "build the upstream code", dh_auto_install means "install the upstream
   software relative to a target directory", and only dh_install is used to
   split the software into component binary packages.  In this case,
   however, we have to know the name of the binary package we're acting on
   to even call mh_patchpoms.  I don't see any way around this, but the net
   effect is that dh_auto_* always have to be called in such a way that the
   main java package is the first package it's acting on - either by being
   listed first in debian/control, or by being passed as a -p option.

 - Above all, this build system does *not* degrade gracefully.  Degrading
   gracefully is one of the most important design criteria of dh(1); if
   dh_auto_build doesn't do what a package needs, that's not supposed to be
   a problem, just override it and call the upstream target by hand.  But
   with maven-debian-helper, that's difficult to do:  far from just being
   able to call 'make', we have to call 'java -noverify -cp [...]
   -Dclasswords.conf= [...]'.  I think it would be a very good idea to
   encapsulate this commandline in some sort of standard wrapper, which
   could then be invoked both by dh_auto_build and by a package's override
   rule when needed.  Something like the 'mvn-debian' command - except that
   mvn-debian is explicitly marked as "not supported" by the maintainers...
   :)  Is that something that could be changed?

I look forward to hearing your thoughts on these questions!

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: maven-debian-helper-dh1.patch
Type: text/x-diff
Size: 6739 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-java-maintainers/attachments/20120108/cb1dc45e/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-java-maintainers/attachments/20120108/cb1dc45e/attachment.pgp>


More information about the pkg-java-maintainers mailing list