From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benz Schenk Subject: Re: Multiple python-3 packages Date: Fri, 27 Jan 2017 16:18:01 +0100 Message-ID: <20170127161801.509cbeb7@gondolin.arda> References: <20170127101225.GA28495@jasmine> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:56198) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cX8Hw-0001mU-UG for guix-devel@gnu.org; Fri, 27 Jan 2017 10:18:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cX8Ht-0000aU-Qa for guix-devel@gnu.org; Fri, 27 Jan 2017 10:18:08 -0500 Received: from idmx01.uzh.ch ([130.60.205.53]:57041) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cX8Ht-0000Zh-JZ for guix-devel@gnu.org; Fri, 27 Jan 2017 10:18:05 -0500 Received: from idsmtp02.uzh.ch ([130.60.206.121]:50734) by idmx01.uzh.ch with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1cX8Hr-0004Et-Lj for guix-devel@gnu.org; Fri, 27 Jan 2017 16:18:04 +0100 Received: from 77-56-36-162.dclient.hispeed.ch ([77.56.36.162] helo=gondolin.arda) by idsmtp02.uzh.ch with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cX8Hr-0005ae-6f for guix-devel@gnu.org; Fri, 27 Jan 2017 16:18:03 +0100 In-Reply-To: <20170127101225.GA28495@jasmine> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: guix-devel@gnu.org On Fri, 27 Jan 2017 05:12:25 -0500 Leo Famulari wrote: > Currently we have Python 3.4 and 3.5. Python 3.6 was released recently. > > When we added 3.5, I thought it was a good idea to keep 3.4 around in > case some packages need it. It turns out that nothing is using it in our > tree. > > Do we want to keep 3.4 and 3.5 around? There is a maintenance cost > incurred at each new release, because their shared patches tend to > diverge each time. As far as my grep-fu tells me, there's no packages that rely on a specific Python 3 release in their definition as of now, so I'd be in favour of dropping the old versions. If packages start to fail because of compatibility issues, I'd say that's a) an upstream issue, which admittedly has to be worked around until they hopefuly fix it, but still b) until the definitions of the affected packages are patched it would happen anyway worst case scenario, the old versions have to be are added again and people just rollback and keep using whatever they have installed atm until the needed version is available again and the package definitions are fixed > > If we should keep them, how should the package inheritance go? Now, it's > like this: > > 2.7 < 3.5 < 3.4 > > If we kept them all, should 3.5 and 3.4 both inherit 3.6? That would make sense