> On 04/06/2015 09:39 PM, Potter, Tim (Cloud Services) wrote: >> Next on the list of Jruby dependencies is an updated version (3.0.10) >> of the jnr-posix library. The current version in the archive is >> out-of-date (1.1.8) and requires libconstantine-java which conflicts >> with any package that requires libjnr-constants-java. I’ve renamed >> this and converted the build system to maven-debian-helper. [snip] > I have pushed a few minor changes and believe that src:jnr-posix in and > of itself is ready for upload to experimental. > > However, eclipse-pydev isn't building after swapping out > libconstantine-java for libjnr-constants-java, so it'll be a bit before > I upload. Also, until the new jnr-ffi hits experimental, jnr-posix > won't build from experimental, so waiting a bit won't hurt. I now have jython building against the new versions of jnr-posix and jnr-constants (pushed to pkg-java in the "debian-experimental" branch - this seems to be a common convention for other teams). gradle needs a similar effort. It's mostly light refactoring, but it takes a bit of time. My question for the list is just how "sloppy" experimental can be during this transition? For example, I could go ahead and upload jnr-posix, which will break the build-r-deps that aren't yet patched, but may also others to get started on transitioning r-deps and eventually allow us to transition more quickly. At some point we'll break things temporarily anyway, since jnr-posix, jnr-ffi, jnr-constants (and jffi?) all need to hit the archive at the same time to allow building of their refactored r-deps. Any thoughts on materializing these new versions as uploads to experimental while we get everything in place? Thank you, tony
Attachment:
signature.asc
Description: OpenPGP digital signature