Re: on the lack of a `python-` prefix for source packages
On Mon, Dec 12, 2022 at 04:36:53AM +0000, Scott Kitterman wrote:
> On December 12, 2022 2:43:48 AM UTC, Sandro Tosi <morph@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 <debian@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.
I agree with Scott's reasoning here. Given that we prefix the binary
packages with python3-, I strongly prefer to keep the source package
name the same as upstream. I feel that way even for python modules and
would vote against the requirement, but can understand and appreciate
the other side of the argument.
> 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).
Agree here as well. Guidelines & reasonable defaults can be helpful for
new contributors, but I really don't think we need a rule here --
whether or not it enshrines my (current) preference.
> Scott K
--Joe
Reply to: