[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Should Binaries provided by python-babel have a "python3-" prefix?

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,
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.


Reply to: