Dear Lev, On Wed, 08 Feb 2017 21:52:12 +0500 Lev Lamberov <dogs...@debian.org> wrote:
> So, there are simply two options: > > 1. Do not build swi-prolog-java on mips (as it already done on armel > and armhf), and let swi-prolog enter stretch. > > 2. Do not let 7.2.3 version of swi-prolog enter stretch. > > As for me I vote for the second option, because I don't think that it > is a good idea to let dead (= without upstream support and without > enough competent contributors in Debian, who is interested to keep it > alive) branch of some piece of software enter stable release and stay > there for 2 or more years. It simply will _not_ have any good support, > which I'd consider as a bad thing. > > My suggestion, as partly stated above, is to have that RC bug open to > not let swi-prolog enter stretch. But after stretch release 7.4 > (moreover 7.4 should have OpenSSL 1.1 support, which is absent in 7.2) > branch of swi-prolog will be ready and I'll upload it to backports. > > But if there are anyone who _really_ need swi-prolog in stretch, I'm > open to your suggestions and can manage with the first option. (In > this case, please, do not expect good level of support of swi-prolog > in stretch.) If swi-prolog is removed from stretch, then several reverse dependencies will also go away (in particular sagemath and ppl maintained by the Debian Science Team, which is what prompted me to fix #852892). So I think you should not remove swi-prolog unless there is no other option. Dropping swi-prolog-java on mips seems a reasonable fix for the FTBFS on that arch. IMO, the only reason why you may want to drop swi-prolog from stretch is if it is impossible to provide security support. If you are unsure about this, you may want to contact the Debian Security Team. Cheers, -- .''`. Sébastien Villemot : :' : Debian Developer `. `' http://sebastien.villemot.name `- GPG Key: 4096R/381A7594
signature.asc
Description: This is a digitally signed message part
