packages names, unless the upstream project already contains it
AFAICT all other major languages ecosystems packaging teams use a >(semi?)mandatory tag to identify their source packages (results below
from a very quick look at Sources, top results only):
prefix: golang, rust, r, node, ruby, haskell, php, ocaml, python (on a >voluntary basis), and others
prefix+suffix: perl
At the beginning, I remember being in favor of the current status quo
in DPT, where each maintainer can choose to add `python-` if they feel
like it, or just use the upstream name.
Thru the years, i've grown more uncomfortable with this situation and
i think the fact we dont mandate a `python` prefix in the team source >packages names (and thus guiding the rest of the python packagers
within Debian towards a common style) is detrimental to Debian as a
whole, and we should change it.
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?
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.
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...
What problem are you trying to solve?
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.
Proposal: the DPT will start adding a `python-` prefix to NEW source
packages names, unless the upstream project already contains it
AFAICT all other major languages ecosystems packaging teams use a (semi?)mandatory tag to identify their source packages (results below
from a very quick look at Sources, top results only):
prefix: golang, rust, r, node, ruby, haskell, php, ocaml, python (on a voluntary basis), and others
prefix+suffix: perl
At the beginning, I remember being in favor of the current status quo
in DPT, where each maintainer can choose to add `python-` if they feel
like it, or just use the upstream name.
Thru the years, i've grown more uncomfortable with this situation and
i think the fact we dont mandate a `python` prefix in the team source packages names (and thus guiding the rest of the python packagers
within Debian towards a common style) is detrimental to Debian as a
whole, and we should change it.
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
`python-`
existing packages at a later date.
What are other team members' opinions on this?
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 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--Joe
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 349 |
Nodes: | 16 (2 / 14) |
Uptime: | 115:59:44 |
Calls: | 7,612 |
Files: | 12,786 |
Messages: | 5,683,796 |