Package: maven-debian-helper Version: 2.0 Severity: important The files in the debian control directory should not be modified during the build of a debian package, or in extreme cases when it can not be avoided any such modifications must be reverted during debian/rules clean, so that when the package build is run a second time it will do the same thing as when run the first time.
Packages using debian-maven-helper currently does not follow this basic
rule because it makes a call to mh_resolve_dependencies as part of the
dh_auto_install invokation.
This call to mh_resolve_dependencies brings havoc and destruction to
several files in the debian directory. It modifies the debian/*.poms
file - which is not at all helpful. It adds rules that not make sense
to the debian/maven.rules and other debian/maven.*Rules files, and even
creates these when they were not previously present. This means that a
lot of the efforts spent on creating these files when making the
package are lost when the package is built, and you have to remember to
restore your work from the debian.tar.xz file before iterating the
build again.
In addition to this the call to mh_resolve_dependencies generates a lot
of entries on the debian/*.substvars file. Most of these make no sense
when mh_resolve_dependencies is run as part of a package build. The
author of the tool is aware of this since the first line in the
debian/*.substvars file it creates is a comment saying these lines
should be copied by hand to the debian/control file. This manual step
is not part of the package build, so the only thing these entries do is
generate warnings about unused tags in the debian/*.substvars file
during the build.
The one entry that makes a bit of sense is the ${maven:Depends} tag,
which could be used to add some dependencies to the binary packages.
However, this tag is not very well implemented since it lumps all the
dependencies of all binary packages as dependencies to the first binary
package that is built by the source package, and no dependencies to the
others. (The first package is usually the parent package that has no
runtime dependencies at all.) It also does not add internal
dependencies between the different binary packages being built by the
source package.
So the call to mh_resolve_dependencies has a huge set of bad unhealthy
side effects, and the one little thing that makes sense of all the
things it does it does rather poorly. So can the call to
mh_resolve_dependencies be dropped from the set of commands run by
dh_auto_install? Possibly it could be replaced with a call to another
tool that creates the ${maven:Depends} tags only and nothing else, and
in a better way than the broken way currently done by
mh_resolve_dependencies.
Calling mh_resolve_dependencies makes some sense from a tool that
creates a set of template files like e.g. mh_make, but once the
templates have been created it should not be called again, since this
will undo any effort by the maintainer of cleaning up the templates of
thing that are not needed or useful for this particular package.
I managed to create a hack in some packages I recently converted to use
maven-debian-helper so that the call to mh_resolve_dependencies was
replace by a no-op, but should such hacks be needed in order for the
package to work as expected?
Mattias
signature.asc
Description: This is a digitally signed message part
