Hi! [ I never received a reply so was not aware some conversation had been going on. :) I've rearranged the replies a bit. ]
On Sun, 2023-01-29 at 13:52:09 +0100, Piotr Ozarowski wrote: > tags 791635 + wontfix > thanks > [Scott Kitterman, 2023-01-29] > > Please wontfix and let's move on. > > +1 > > IMO source package names should follow upstream as closely as possible If Debian only contained python packages, that would make sense, because python modules upstream need to care about not stomping over each others names. But Debian contains source packages for multitude of projects and language ecosystems, where their own modules can and do share the same short and generic or conflicting module names with many other language ecosystems modules (say json modules). These also can conflict with command-line tools which use another common namespace, etc. Pretty much every other language specific team in Debian namespaces their _source_ and _binary_ packages to avoid stomping/grabbing on the global namespace. I don't really understand what makes python special here, that it cannot follow a similar pattern. :/ On Mon, 2023-02-06 at 11:52:35 -0500, Scott Kitterman wrote: > On Monday, February 6, 2023 9:23:17 AM EST Stefano Rivera wrote: > > Hi Scott (2023.01.29_01:34:54_+0000) > > > Regardless, I don't think this is an appropriate use of FTP Team > > > time/energy. I was under the impression that these did still not require NEW trips, or had not associated that the dak support for overrides for sources implied that renames for these now (obviously) need to go through NEW, until Scott mentioned this on d-d (thanks!). Which while it makes sense that they'd also go through NEW, it now implies cleanups like this cannot be easily done w/o going through additional hoops. I do think though that this kind of thing is precisely what a NEW check should be doing (and used to imply too, long ago AFAIR), as the archive admins are responsible for both the contents (f.ex. license-wise), organization (overrides) and the *namespace* of the packages in the archive. > > +1. I could live with this being a recommendation for new source > > packages, but it don't really see the value in renaming existing source > > packages. > I definitely think any changes ought to be new packages only. > I could live with "upstream name or python-$modulename" for the source > package. Generally when I've deviated from python-$modulename it's been to > align to the upstream naming convention. 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, but it's hard to tell from just "upstream name", given what I've seen. :) The above, and restricting to only new source packages, still seems rather unsatisfactory to me, in terms of namespace handling, and management of such shared resource. But, assuming the "upstream name" part can be made less fuzzy, I'd take a policy that stops making the problem worse, and which applies only to new source packages, than none at all. I can try to propose new wording. > > Also, as I've said before on this topic, every packaging rule is a > > barrier to entry for new contributors. We really shouldn't add > > things that aren't needed. See above for the reasoning. I can relate to that in the extreme, but to me the key is that managing namespaces is precisely one of the essential things a distribution does and needs to do, as part of its integration and cohesion work to make all those random and disparate parts that we are gluing together work in concert, and in a way that is easier to understand and handle at scale. Thanks, Guillem
