Bug#807686: Do not modify the debian control files during package build

[Mattias Ellert]

fre 2015-12-11 klockan 16:58 +0100 skrev Markus Koschany:
> 
> Hi,
> 
> could you provide an example package where maven-debian-helper
> modifies
> files in your debian directory? What helper tools (dh, cdbs, pure
> debhelper) and compat level do you use?
> 
> Thanks,
> 
> Markus

Hi!

When I converted my Debian Java packages from mvn-debian, I used dh.
All of them are affected by this issue:

canl-java
jglobus
voms-api-java
voms-clients-java

So you can look at any one of them.

They all have a workaround implemented: there is a dummy
debian/mh_resolve_dependencies script that does either nothing or only
touches a debian/*.substvars file, and there is a
override_dh_auto_install rule that changes the PATH during the
dh_auto_install call so that the call to mh_resolve_dependencies gets
replaced with a call to this dummy script.

override_dh_auto_install: 
	PATH=$(CURDIR)/debian:$${PATH} dh_auto_install 

This way the packages work fine.

If the workaround is removed, then after you have run dpkg-buildpackage 
once, these files have been modified or overwritten:

debian/*.poms
debian/maven.rules
debian/maven.ignoreRules

and these files not present in the original source package have been
created:

debian/maven.publishedRules
debian/maven.cleanIgnoreRules

These changes are not reverted by debian/rules clean, so if you run
dpkg-buildpackage again the packages would be built using a different
set of rules than during the first build - which makes the packages
broken.

The debian/compat says "5", because this is what it was before I
converted the packages to use dh - and there were no indications from
lintian that this would not be sufficient. Changing the debian/compat
to "9" doesn't change anything - mh_resolve_dependencies is still
called during the build and the same breakage occurs.

In the code in /usr/share/perl5/Debian/Debhelper/Buildsystem/maven.pm -
which is installed by the maven-debian-helper package:

In the "sub install" the first $this->doit_in_builddir calls maven to
do the installation - this part you really want.

The very next line is another call to $this->doit_in_builddir which
calls mh_resolve_dependencies and is the one that brings havoc and
destruction.

There are no conditionals in the code here that makes it possible to
have to call to maven without the call to mh_resolve_dependencies, so
there doesn't seem to be any why to make the breakage not happen except
for hacks like the one I used.

Removing the call to mh_resolve_dependencies would be a way to fix it:

$ diff -ur maven.pm~ maven.pm
--- maven.pm~	2015-12-11 14:47:56.000000000 +0100
+++ maven.pm	2015-12-16 16:20:02.280000000 +0100
@@ -108,11 +108,7 @@
 		"-Dmaven.repo.local=$this->{cwd}/debian/maven-repo",
 		"-Dinstall.to.usj=true",
 		"org.debian.maven:debian-maven-plugin:$maven_debian_version:install");
-	$this->doit_in_builddir("mh_resolve_dependencies", "--non-interactive",
-		"--offline", "-p$this->{package}", @resolvedep_args);
 	if ($this->{doc_package}) {
-		doit("cp","debian/$this->{package}.substvars",
-			"debian/$this->{doc_package}.substvars");
 		# clean up generated docs
 		$this->doit_in_builddir("rm", "-f", "target/apidocs/*.sh",
 			"target/apidocs/options");


	Mattias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-java-maintainers/attachments/20151216/bf52b7d2/attachment.sig>