On October 18, 2024 2:07:35 PM UTC, Simon McVittie <s...@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
