Am 12.10.2017 um 01:12 schrieb Emmanuel Bourg: [...] > Could we keep the --has-package-version flags please? If we change the > behavior of maven-debian-helper in a near future putting them back in > all packages is going to take a lot of time. There is really no harm > keeping them for now.
First of all I believe such discussions should be held before a major change in maven-debian-helper is implemented and not afterwards. What are your plans for maven-debian-helper and what do you mean by changing the behavior in the near future? The only reason why I kept --has-package-version in basically all my maven packages was because it was a default value when I created a new package with mh_make. Nowadays, you told me that yourself, --has-package-version is no longer the default. Why would I need this flag anyway? As far as I can see even without the most recent change, it does nothing of any importance. My packages work exactly as they should without this flag, so why should I worry about it? Now you have implemented a new feature and changed the behavior of --has-package-version. Reverse-dependencies will now add a strict >= versioned dependency to their Depends field but only for Maven packages. All other build systems will behave completely different! Imagine we would do the same change for C/C++, Perl or Python packages. Oh let the fun begin. There is a good reason why debhelper uses compatibility levels. Sure, if you implemented something like --has-versioned-dependency, everything would have been fine. A new option, everyone can opt-in. At the moment I am simply unconvinced that this feature improves my packaging work. Even worse it broke one of my packages and that's why I decided that I don't really need it. In addition if this is really the feature we want to have in every Maven package, the Java Policy should be adjusted and recommend it. And while we are at it: I totally appreciate your work on Maven and maven-debian-helper but we could improve something in the communication and efficiency department. New features that break existing packages or have other major impacts should be announced on this list before they go live. The Maven 2 -> Maven 3 switch: My ideas Break one major package or package chain, then wait for the bug reports or even better anticipate them. There is usually a pattern and a clear solution. Ask for help, outline what you want to achieve, so that people can contribute something towards that goal. As soon as this stage is cleared, move on to the next and repeat. The reality looks like: Before step 1 is completed, new cans of worms are opened. It becomes very hard to fix something because suddenly one package can be affected by two different or more issues. But more complexity means it takes more time to investigate and fix those bugs. I'm sure there is a better and more linear approach. I want to avoid that someone who is not me burns out, tries to solve every problem single-handedly and in the end nobody knows what is going on and is thus unable to help. Regards, Markus
signature.asc
Description: OpenPGP digital signature
