-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Hello,
I would like to hear opinion of other packagers about naming. We have `parallel` utility implemented in Rust which is drop-in replacement for GNU parallel. I was thinking how to name package and how people would expect it to be named. So far options are:
* rust-parallel * parallel-rust * parallel-rs
I dislike first one because it is not ending up in completion while second and third are quite good.
Thoughts? - -- - -Igor Gnatenko
What about an analogy with 'createrepo'? We have:
* createrepo * createrepo_c
Using this same analogy:
* parallel_rust * parallel_rs
On Mon, Dec 4, 2017 at 10:20 AM, Igor Gnatenko < ignatenkobrain@fedoraproject.org> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Hello,
I would like to hear opinion of other packagers about naming. We have `parallel` utility implemented in Rust which is drop-in replacement for GNU parallel. I was thinking how to name package and how people would expect it to be named. So far options are:
- rust-parallel
- parallel-rust
- parallel-rs
I dislike first one because it is not ending up in completion while second and third are quite good.
Thoughts?
- -Igor Gnatenko
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlolE00ACgkQaVcUvRu8 X0zcDg/+J4jaboaEmySwsgHiSNDfVqazoxrcZDp0abS8wRO9jSxXCPU0K/MpBgtg W3LnJOkEhr4WjRtwoC4MmvZf99sfBo4q6ATfd2hOg0WeYkwP36Fu9lVZUAEP6V0E zVNp44UCuxJNU9IxUvop4XVJOTmaF0Be3pGrJ2LRliZkIgJgzVwOk8pkv/eO1iwp Y5j2VK7Wjs1Z2/tuL6/u02GqZOpD/0NE145awQUp2PFNwIwYeP70UZ5OjoqdLPNO LAWybGPSuoaLN7xT7F3FFvqUBhU6Ypsnc2trd01DyJ81v8ITxeAxZpyMy/jLsoyU 0RyP5UJyzI/joGNLHDQimmBnBH3SOcVr68Sx2TIMLxmsyCFaGmv+ehZlTkRWocnM QWc0fKOD5FC9W7NY21NOCADG6tuIjj+n8Ncw27gbZ0gexbq/drcq9J7aaiKZ0USf HA7iKya6OiuSKI2GAzKGMcBzp3GKkcUl+3NSBOw2bB/fF1NneXJDL4FkQVhvC+Ta G9Hmz3MC+f/amozta7y+pPAzswf5yzArc1Lcw/HWx3QG3S/DAlR+fnJntf+Rgz6I KRYyasi+RLUizzxBnlOXsi3PM3ppErHXmCfewyyhNup0T+DQsW3Na9/q6nWea/1+ I2WA3kZEmoYHEZM5d3r4I3vPliz0QXJQjNkpicqCxg+A85CBH44= =TEXI -----END PGP SIGNATURE----- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On Mon, 2017-12-04 at 10:50 +0100, Adam Samalik wrote:
What about an analogy with 'createrepo'? We have:
- createrepo
- createrepo_c
That's only because createrepo_c is upstream name.
Using this same analogy:
- parallel_rust
- parallel_rs
This is really worst user experience. - -- - -Igor Gnatenko
Hi,
I'd go with parallel-rs as the "-rs" ending is used often with Rust projects. e.g. dbus-rs or gtk-rs.
Martin
On 12/04/2017 11:20 AM, Igor Gnatenko wrote:
Hello,
I would like to hear opinion of other packagers about naming. We have `parallel` utility implemented in Rust which is drop-in replacement for GNU parallel. I was thinking how to name package and how people would expect it to be named. So far options are:
- rust-parallel
- parallel-rust
- parallel-rs
I dislike first one because it is not ending up in completion while second and third are quite good.
Thoughts? _______________________________________________ Rust mailing list -- rust@lists.fedoraproject.org To unsubscribe send an email to rust-leave@lists.fedoraproject.org
On Mon, 04 Dec 2017 10:20:13 +0100, you wrote:
I would like to hear opinion of other packagers about naming. We have `parallel` utility implemented in Rust which is drop-in replacement for GNU parallel. I was thinking how to name package and how people would expect it to be named. So far options are:
- rust-parallel
- parallel-rust
- parallel-rs
I dislike first one because it is not ending up in completion while second and third are quite good.
To me the second and third make it look like the package is part of the existing parallel package - perhaps rust bindings to parallel - and not an entirely different program.
In other words, I could see people install parallel-rust because "it must be part of the parallel package" based on its naming and not realize it is an entirely different program doing the same thing.
On Mon, Dec 04, 2017 at 09:19:26AM -0500, Gerald Henriksen wrote:
On Mon, 04 Dec 2017 10:20:13 +0100, you wrote:
I would like to hear opinion of other packagers about naming. We have `parallel` utility implemented in Rust which is drop-in replacement for GNU parallel. I was thinking how to name package and how people would expect it to be named. So far options are:
- rust-parallel
- parallel-rust
- parallel-rs
I dislike first one because it is not ending up in completion while second and third are quite good.
To me the second and third make it look like the package is part of the existing parallel package - perhaps rust bindings to parallel - and not an entirely different program.
In other words, I could see people install parallel-rust because "it must be part of the parallel package" based on its naming and not realize it is an entirely different program doing the same thing.
Yes. In other words, the problem started when somebody decided to reimplement a well-known existing package in a different language without changing the name. It seems like the right solution is to ask the rust-parallel folks to rename their project instead of squatting on an existing name.
Zbyszek
Perl: perl-foo Python: python-foo NodeJs (NPM): nodejs-foo Ruby: rubygem-foo R: R-foo PHP: php-foo Golang: golang-foo
The prefix pattern "rust-parallel" looks better.
Jun
On Mon, Dec 4, 2017 at 3:45 PM, Zbigniew Jędrzejewski-Szmek < zbyszek@in.waw.pl> wrote:
On Mon, Dec 04, 2017 at 09:19:26AM -0500, Gerald Henriksen wrote:
On Mon, 04 Dec 2017 10:20:13 +0100, you wrote:
I would like to hear opinion of other packagers about naming. We have `parallel` utility implemented in Rust which is drop-in replacement for
GNU
parallel. I was thinking how to name package and how people would
expect it to
be named. So far options are:
- rust-parallel
- parallel-rust
- parallel-rs
I dislike first one because it is not ending up in completion while
second and
third are quite good.
To me the second and third make it look like the package is part of the existing parallel package - perhaps rust bindings to parallel - and not an entirely different program.
In other words, I could see people install parallel-rust because "it must be part of the parallel package" based on its naming and not realize it is an entirely different program doing the same thing.
Yes. In other words, the problem started when somebody decided to reimplement a well-known existing package in a different language without changing the name. It seems like the right solution is to ask the rust-parallel folks to rename their project instead of squatting on an existing name.
Zbyszek _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
"JA" == Jun Aruga jaruga@redhat.com writes:
JA> Perl: perl-foo Python: python-foo NodeJs (NPM): nodejs-foo Ruby: JA> rubygem-foo R: R-foo PHP: php-foo Golang: golang-foo
Those are all for libraries in the given language.
JA> The prefix pattern "rust-parallel" looks better.
This is not a library written in rust.
https://fedoraproject.org/wiki/Packaging:Guidelines#Library_or_Application.3...
If you discount the guidelines for multiple parallel-installable versions of the same package, we don't really have an established naming convention for alternate versions of a "thing". Best I can think of are things like libart_lgpl (which doesn't and maybe never did have a non-lgpl version), reentrant versions of libraries like libqhull_r (which has the least useful package %description I've ever seen), though those aren't generally packaged separately, or, I don't know, chromium-libs-media-freeworld (which I know isn't a Fedora package).
Honestly I'd just pretend that what you have really _is_ a different version of the same package, but instead of being version '3', it's version 'rust'. And for that we have https://fedoraproject.org/wiki/Packaging:Naming#Multiple_packages_with_the_s... which would suggest "parallel-rust".
For the actual executables, we have a long tradition of prefixing 'k' for kerberized versions of things, and postfixing version numbers, sometimes with dashes. Which really doesn't clarify much of anything. About all we can say with certainty is that this package can't install /usr/bin/parallel.
- J<
Jason,
If you discount the guidelines for multiple parallel-installable versions of the same package, we don't really have an established naming convention for alternate versions of a "thing".
Thanks for mentioning it and the detailed explanation. I did misunderstand it. I understand what you are talking about. Yeah, the suffix style "parallel-rust" looks better.
Jun
On Mon, Dec 4, 2017 at 11:10 PM, Jason L Tibbitts III tibbs@math.uh.edu wrote:
"JA" == Jun Aruga jaruga@redhat.com writes:
JA> Perl: perl-foo Python: python-foo NodeJs (NPM): nodejs-foo Ruby: JA> rubygem-foo R: R-foo PHP: php-foo Golang: golang-foo
Those are all for libraries in the given language.
JA> The prefix pattern "rust-parallel" looks better.
This is not a library written in rust.
https://fedoraproject.org/wiki/Packaging:Guidelines# Library_or_Application.3F
If you discount the guidelines for multiple parallel-installable versions of the same package, we don't really have an established naming convention for alternate versions of a "thing". Best I can think of are things like libart_lgpl (which doesn't and maybe never did have a non-lgpl version), reentrant versions of libraries like libqhull_r (which has the least useful package %description I've ever seen), though those aren't generally packaged separately, or, I don't know, chromium-libs-media-freeworld (which I know isn't a Fedora package).
Honestly I'd just pretend that what you have really _is_ a different version of the same package, but instead of being version '3', it's version 'rust'. And for that we have https://fedoraproject.org/wiki/Packaging:Naming# Multiple_packages_with_the_same_base_name which would suggest "parallel-rust".
For the actual executables, we have a long tradition of prefixing 'k' for kerberized versions of things, and postfixing version numbers, sometimes with dashes. Which really doesn't clarify much of anything. About all we can say with certainty is that this package can't install /usr/bin/parallel.
- J<
-
Adam Samalik -
Gerald Henriksen -
Igor Gnatenko -
Jason L Tibbitts III -
Jun Aruga -
Martin Sehnoutka -
Zbigniew Jędrzejewski-Szmek