On December 12, 2022 2:43:48 AM UTC, Sandro Tosi <mo...@debian.org> wrote:
>> >> My proposal as stated at the top is to start from now on to prepend
>> >> `python` to all NEW source packages in DPT, with the option to rename
>> >> existing packages at a later date.
>> >>
>> >> What are other team members' opinions on this?
>> >
>> > For packages that on contain a python module/extension, I think it's not
>> > horrible, but I don't see why it's better to diverge from upstream naming.
>>
>> I tend to agree with Sandro on for this use case.
>
>True, i was mostly referring to modules, as that's the most numerous
>type of packages we have
>
>> > For packages that contain or are primarily applications, I don't think
>> > it's a good idea.
>>
>> Ditto on that one, I don't feel having "python-supysonic" would be a
>> good naming scheme...
>
>please note that would be just for source packages, the user-facing
>ones can still be `supysonic` as that's what you expect to install
>
>On Sun, Dec 11, 2022 at 8:53 PM Scott Kitterman <deb...@kitterman.com> wrote:
>> What problem are you trying to solve?
>
>no problem specifically, i just feel that having a consistent scheme
>would benefit Debian and then team.
If it's a case where multiple languages would likely have a package with
similar naming, I can see it's a good thing to be clear. When we already don't
use the same name as upstream in the binary (what upstream has python3- in the
package name?), I think there's value in using the exact upstream name for the
source package.
As an example, I maintain dkimpy (also the upstream name) which has the
python3-dkim binary package. If this were a new package that would follow your
proposed rule, what would the source package be named? If it's python-dkim,
that would follow your proposal, but a new user that knew the upstream name
would find nothing if they searched for it. Python-dkimpy would solve that,
but seems redundant.
I don't see how having an additional rule is helpful. I think every rule we
add makes it more complicated for new contributors, so we should be careful to
avoid adding new ones without good reason (and it wouldn't hurt to revisit old
ones and ditch things that have outlived their usefulness).
Scott K
