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

Re: Need help with naming scheme in debian/control for python library



On Tue, 01 Jul 2025 at 10:42:19 +0200, Carsten Schoenert wrote:
Am 01.07.25 um 09:59 schrieb Aryan Karamtoth:
...
So my question is should I rename the source field to “python3- packagename” too or will it cause any conflicts?

The source package ("Source:") should not be prefixed with "python3-", even if the binary package ("Package:") is. This is because, if there is a Python 4 in future, we might want to build both python3-foo and python4-foo binary packages from the same source package, which would normally be called python-foo.

If the source package name ("Source:") needs a disambiguating prefix, use "python-" instead of "python3-" for that.

the common sense is to prefix the source package with "python" without any version numbers.

Usually, yes. If the upstream name of the software is something that could easily collide with similarly-named packages outside the Python ecosystem (like for example "keyring", https://github.com/jaraco/keyring) then prefix it with "python-" (which is what has been done in https://salsa.debian.org/python-team/packages/python-keyring/-/blob/debian/master/debian/control?ref_type=heads).

But if the upstream name of the software already makes it obvious that it's for Python (like for example dbus-python, tap.py or pygobject) then there isn't necessarily any need to prefix "python-" to that as well.

If you are not sure, the safe choice is to prefix "python-".

Aryan, you would probably get clearer advice if you name the specific package you are working on, rather than saying "packagename".

There is some discussion of this naming convention in https://bugs.debian.org/791635, and I think it would make sense for the Python policy to say something about this (although I don't agree with the suggestion to require a python- prefix on *every* source package name for Python libraries, because something like python-dbus-python would be silly).

Have a look at existing packages.

Yes, this. There are lots of good examples.

    smcv


Reply to: