Am 02.10.2017 um 18:35 schrieb Emmanuel Bourg: > Le 2/10/2017 à 17:51, Markus Koschany a écrit : > >> There is at least one major downside of the current behavior. You >> completely loose the flexibility to choose that your package is able to >> run with an older version of libfoo. There is always a strict dependency >> on the latest version which can be a real hassle if you try to backport >> packages. Unfortunately we don't have a C/C++ mechanism like symbols >> files in Java but the answer should not be to enforce a dependency on >> the latest version. > > Ideally the version used for the resolved dependencies should be the > ones defined in the pom, such that the packages express the same > requirements than the Maven artifacts they contain. That would be a less > strict middle ground. In my opinion this should have been a new option where users can choose to opt-in. I find it less than optimal that the behavior of an existing option was changed without further notice and documentation and now everyone is expected to cope with the situation. > Regarding the backports, what the current maven-debian-helper behavior > really limits is the ability to download a .deb built for sid and > install it directly in stable. That would be an interesting feature but I think it is unrelated to the problem at hand. Rebuilding the package for stable is > still possible with no extra modification, and the resolved dependencies > will then refer to the versions in stable. Ok, this is true. But the dependency will be >= the latest version in backports or stable. This makes it more complicated to use customized packages. In the end the user is forced to override the strict dependency in debian/control if he prefers to use an earlier package version. Markus
Attachment:
signature.asc
Description: OpenPGP digital signature