From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Enge Subject: Re: [PATCH] gnu: Add Scikit-learn. Date: Thu, 26 Feb 2015 21:43:09 +0100 Message-ID: <20150226204309.GA12643@debian> References: <20150223175238.GA10579@debian.eduroam.u-bordeaux.fr> <20150225225215.GA13330@debian> <20150225225740.GA13495@debian> <87bnkg61js.fsf@gnu.org> <20150226175900.GA3835@debian> <648692e7170fada41ebd45ebe0724e42@openmailbox.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:60560) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YR5HD-0000ZP-0y for guix-devel@gnu.org; Thu, 26 Feb 2015 15:43:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YR5H8-0001KC-Vc for guix-devel@gnu.org; Thu, 26 Feb 2015 15:43:18 -0500 Content-Disposition: inline In-Reply-To: <648692e7170fada41ebd45ebe0724e42@openmailbox.org> 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-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Eric Bavier Cc: Guix-devel On Thu, Feb 26, 2015 at 02:03:37PM -0600, Eric Bavier wrote: > The issue in this case is that py2cairo and pycairo are actually different > projects. I chose to use the name python2-py2cairo, to go with our "least > divergence from upstream" method. Both seem to belong to the "pycairo" project: http://cairographics.org/pycairo/ which produces two different tarballs, one for Python 2 and one for Python 3, that are released with the same version. So I think it would make sense to in any case choose a common base name, be it "pycairo". That would also avoid the problems with dependencies that Ricardo faced. We recently discussed that we can choose the "project name" over the "tarball name" in another example. > >that is, use the module name for > >a package containing a single module. > This could become error-prone. The packager needs to check the interface of > the library before deciding on a package name? It might also not be > future-proof, in the event that a project updates its public interface. Indeed, the new rule would require to have a look at the output of a package to count the number of modules... I copied it from the Perl case; are things different there, and each module is distributed in a separate tarball for Perl? I think the question of being future proof is not such a big problem, we can always modify package names (with a bit of work, of course). So you would suggest to always use the "project name" and not the "module name" for Python packages? Andreas