Le 3/02/2016 13:53, Markus Koschany a écrit : > I like having one source package src:groovy that always provides the > latest upstream release and all its reverse-dependencies shall always > work flawlessly with it. Amen. :-)
+1 The user experience is important to me, and I think 'apt-get install groovy' is more intuitive than 'apt-get install groovy<guessthelatestversionavailable>'. But it doesn't mean the groovy package has to be built from src:groovy. > So I would prefer to package the next version of groovy 2.x > in src:groovy and to remove src:groovy2. I can see the benefits of > option number three but it should be limited to packages where we also > provide an alternative like switching between two different JDKs and > when many, if not all Java packages, are affected by this choice. I also thought the option 2 was a good idea, and as I updated groovy2 to the latest version yesterday I hesitated to do it. I wasn't sure about the upgrades and the backports: - We probably want the Jessie users of the groovy and groovy2 packages to end up automatically with the latest Groovy 2.x when upgrading to Stretch. This means we have to keep a groovy2 binary package (either with the full runtime or just a dummy dependency package). - Backporting groovy2 to Jessie might be more complicated if we switch back to src:groovy. It isn't just a rebuild, we have to rename the binary packages and change the paths too. > So for me it's option 2 but don't we have to switch the r-deps in > debian/control from groovy2 back to groovy again? Well yes, unless src:groovy also builds a dummy groovy2 package depending on groovy. It would be nice to return to 'debian' artifacts instead of '2.x' too, that's one less rule to worry about when packaging new projects, but this means we have to change the rdeps (or provide 2.x->debian symlinks). Emmanuel Bourg
