On Mon, Dec 12, 2022 at 04:36:53AM +0000, Scott Kitterman wrote: > 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.
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
