Re: Groovy packaging
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
Reply to: