Path: csiph.com!2.eu.feeder.erje.net!3.eu.feeder.erje.net!feeder.erje.net!news2.arglkargh.de!news.mixmin.net!aioe.org!bofh.it!news.nic.it!robomod
From: Simon McVittie <smcv@debian.org>
Newsgroups: linux.debian.maint.python
Subject: Re: Should Binaries provided by python-babel have a "python3-"  prefix?
Date: Fri, 27 Nov 2020 13:20:02 +0100
Message-ID: <BfKTg-1ty-7@gated-at.bofh.it>
References: <BfoJ3-4JH-3@gated-at.bofh.it> <Bfx9D-1xK-3@gated-at.bofh.it>
Old-Return-Path: <smcv@debian.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Approved: robomod@news.nic.it
Lines: 47
Organization: linux.* mail to news gateway
Sender: robomod@news.nic.it
Xref: csiph.com linux.debian.maint.python:13030

On Thu, 26 Nov 2020 at 22:33:19 +0100, Steffen Möller wrote:
> On 26.11.20 13:16, Nilesh Patra wrote:
> > Currently src:python-babel provides 3 binaries:
> >
> > * python3-babel
> > * python-babel-doc
> > * python-babel-localedata
> >
> > of which python3-babel is the main binary, -babel-doc is for the
> > documentation and -babel-localedata is for storing locale data files
> > used by python3-babel.
> >
> > Should this be renamed to a "python3-" prefix for both binaries? They
> > do not contain any actual code though
>
> I propose to have the "3" only for packages that depend on python3. The
> source package name, documentation and data package names should not be
> versioned.

For the documentation,
https://www.debian.org/doc/packaging-manuals/python-policy/module_packages.html
says python-babel-doc is correct (I wrote this wording, but the
python3-defaults maintainers merged it and I think there's consensus
that it's right):

    If the documentation for a module foo provided in python3-foo is
    large enough that a separate binary package for documentation is
    desired, then the documentation package should preferably be named
    python-foo-doc (and in particular, not python3-foo-doc).

For the locale data, the policy doesn't say either way (Python libraries
with separate version-independent data are somewhat rare), but I agree that
python- is likely to be the most appropriate choice here too.

A good way to decide this is to think about what we would do if we had a
Python 4 that is incompatible with Python 3 (which I assume will happen
eventually, although hopefully not for a few years). If these packages
would be shared between python3-babel and python4-babel, then they should
be named with an unversioned python- prefix. That's the reasoning for why
the documentation gets a python- prefix.

The unversioned python- namespace is shared between "Python 2 specifically"
and "not specific to a Python version" for historical reasons: Python 1.x
and 2.x were sufficiently compatible that there was no need to distinguish
between python1-foo and python2-foo.

    smcv