Re: [PATCH] gnu: Add Scikit-learn.

[Andreas Enge <andreas@enge.fr>]

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