On 06.12.2016 16:31, tony mancill wrote: > On Tue, Dec 06, 2016 at 11:22:46AM +0100, Thorsten Glaser wrote: >> On Mon, 5 Dec 2016, Felix Natter wrote: >> >>> 2. Could someone please help analyse the underlying problem >> >> I was also bitten by this problem: >> >> https://lists.alioth.debian.org/pipermail/pkg-java-commits/2016-December/062915.html >> >> On the other hand, Squirrel-SQL is not uploaded to Debian yet, >> so that’s nobody’s fault. >> >> But I think we basically have to assume that the exact contrary >> of what the jgoodies website states is true, i.e. that every new >> version breaks all rdeps, both at compile and at runtime. > > <long stream of expletives deleted>... I'm frustrated by this because > I thought we had addressed the compile-time rdeps by building everything > and reaching out to package maintainers when there was compile-time > breakage. And I didn't anticipate the run-time breakage. Long-term, I > think it is worth discussing how best to support Java applications in > main, since it often feels like we're swimming against the stream trying > to support system-level JARs for everything packaged for Debian. > > But short-term, I'd like to ask for the team's input on what I needs to > do to clean up the mess I have made by introducing the new version. Is > it sufficient to rebuild all rdeps and then upload after a quick > run-time test? > > Thanks for the input, and sorry for the noise, Hi, I agree it is often difficult to bring the Java and Debian philosophies together and we should use only one version of a Java library whenever possible but we should also be flexible as Emmanuel already pointed out. We could write autopkg tests or implement some other QA system but most of the transitions are controllable, that means FTBFS issues are quickly detected (thanks to the reproducible builds effort or the QA team) or our own rebuilds. Runtime breakage is rather rare and it will be detected if nothing else by users in time for the next stable release. I wouldn't worry to much about JGoodies now. We are already at the end of the Stretch release cycle but there is still one month left to clean everything up. Best and most time saving option IMO would be to ask the release team to binNMU all reverse-dependencies. I know transition freeze was on 5th of November but hey, let's talk to them and see how they react. Otherwise we just split the work between all active DDs and rebuild all reverse-dependencies. That should do the trick. Regards, Markus
Attachment:
signature.asc
Description: OpenPGP digital signature