Bug#874494: rebuilding libsambox-java generates unmet dependency on libsejda-io-java (>= 1.1.3.RELEASE)

[Markus Koschany]

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?



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-java-maintainers/attachments/20170906/d857e3f8/attachment-0001.sig>