Am 06.09.2017 um 15:08 schrieb Emmanuel Bourg: > Le 6/09/2017 à 14:51, Matthias Klose a écrit : > >> rebuilding libsambox-java generates unmet dependency on libsejda-io-java (>= >> 1.1.3.RELEASE) >> >> $ dpkg -I ../libsambox-java_1.0.34-1_all.deb | grep Depends >> Depends: libcommons-io-java, libfontbox2-java (>= 2.0.7), libsejda-io-java >> (>= >> 1.1.3.RELEASE), libslf4j-java (>= 1.7.25) > > This is an issue with libsejda-io-java, the --has-package-version flag > was mistakenly used [1]. This led maven-debian-helper to think that it > could use the version in the pom as a version constraint at the package > level, which is wrong in this case due to the ".RELEASE" suffix (this > behavior was broken before maven-debian-helper 2.2, see #862894).
If I understand correctly the behavior changed in maven-debian-helper 2.2 and all Maven packages that build-depend on a package which specifies --has-package-version will automatically use a version constraint from now on? Please note that --has-package-version is used by default when new packages are created with mh_make and I believe most Maven packages that I have touched use this flag in some way. > The solution is to either: > - add the ".RELEASE" suffix to the package version > - remove the suffix from the version in the pom > - remove the --has-package-version flag I can remove the --has-package-version again and work around the version constraint but I believe the issue is more complex. In my opinion there shouldn't be an automatic version constraint unless explicitly specified by the maintainer. I fear a lot more packages are affected and version constraints will be too strict and cause more of these issues. Do we really need to remove --has-package-version if we don't want a versioned constraint or can't we just treat --has-package-version and automatic version constraints differently in m-d-h to get back a more fine-grained control?
signature.asc
Description: OpenPGP digital signature
