On October 18, 2024 2:07:35 PM UTC, Simon McVittie <
smcv@debian.org> wrote:
On Fri, 18 Oct 2024 at 15:31:26 +0200, Guillem Jover wrote:
I guess whether "upstream name or python-$modulename" would seem fine,
depends on what "upstream name" is. I guess if the latter is something
like "py<something>" or some widely known sub-ecosystem that is
really very much python-specific, and there is no chance of that ever
being present in other language ecosystems (which ahem), then I guess
that could be fine
src:dbus-python, src:tap.py and src:pygobject seem like some examples of >upstream names that are fine (not going to conflict with other ecosystems) >despite not fitting the /^python-/ pattern.
But, looking at some packages that I happen to have installed, I think
I agree with Guillem that names like src:alabaster and src:binaryornot
seem too generic to be ideal.
I think forcing a bunch of renaming for existing packages is a waste of effort. If there is a namespace problem it has already happened. For specific cases where there's an actual conflict to resolve, we should do that. For the theoretical cases, we
should leave them alone.
I don't have any objection to a new requirement for the name being distinctive for new source packages, but I don't think we should specify exactly the name that's required.
It's not reasonable to assume that all FTP Team members that might review a package in New are familiar with all language specific policies in Debian. If you want to have the FTP Team enforce something, it needs to go in Debian policy. This is probably
feasible as a generic rule about language specific implementations having source and binary package names that don't squat on generic names.
Scott K
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)