Re: [arch-dev-public] SDR package naming
Hi all, I want to bring up two issues relating Kyle Keen's packages. I tried to contact him and got an initial reply but I have not heard from him since. It has been almost 4 months and I have sent him 3 different followup emails. Since it was not super urgent I let a pretty significant amount of time pass but I would like to have this resolved. Here are the two issues I seek resolution: 1) Rename libuhd to uhd UHD[1] is the upstream name. The software is pretty well known by that name. I have only ever seen it being addressed as libuhd when talking about the library it provides specifically, but even then UHD is the standard. It also provides some tools alongside the library. Following the Arch philosophy I think the package should be named "uhd". 2) Use the gr- prefix instead of gnuradio- for GNURadio[2] blocks The GNURadio ecosystem has a pretty well established prefix for GNURadio blocks, which is gr-. Similarly to the previous issue, I have never seen them being refereed as gnuradio-something. The upstream names are gr-something. The gnuradio- prefix might seem to make things more clear to new users, and even then I have my doubts, but it definitely makes things more confusing for actual users of the project. Previewing some counter-arguments to this, as I have discussed it with people previously. This is totally different than, for eg., the python ecosystem where we use the python- prefix. The gr- is given by the upstream and is the *de facto* naming scheme for the project. If you don't agree with the use of the gr- prefix, I think that variation of the name should *at least* be present in provides. These might seem like nitpicks, but I do very much care about them and I believe they should be corrected. You can find my attempt at communication with Kyle below. I am very conflicted about this, but I think before I end the email I should note that Kyle is packaging and he appears to have replied to other team member(s). I am not sure if I have done something wrong or behaved in an improper manner. I don't think I did, but if that's the case please let me know. [1] https://github.com/EttusResearch/uhd [2] https://github.com/gnuradio Cheers, Filipe Laíns On Thu, 2020-02-06 at 09:42 +0000, Filipe Laíns wrote:
On Wed, 2020-02-05 at 23:21 -0500, keenerd wrote:
Sometimes my automatic email filing puts things in the wrong place, but searching across all folders finds no emails from you about this. How did you try to contact me before?
UHD I am ambivalent on. However several other distros also call it "libuhd" and it is a library after all.
Gnuradio vs gr I don't agree with. A project needs to be very notable for a two-letter naming convention. Python, for example, is sufficient. Internally the Gnuradio project uses "gr" because, well, they type it hundreds of times every day. Outside of their project, it is less helpful and more confusing.
There are several people deeply involved with Gnuradio who are also Arch users. I more or less started packaging Gnuradio for them, and their input was instrumental in making our packages the way they are. They've never raised any of these issues.
You did not provide any reasoning for why you think changes are necessary?
-Kyle
On 2/4/20, Filipe Laíns <lains@archlinux.org> wrote:
Hey Kyle,
I think I have contacted out about this already but without much success. I would like to adjust the names of some SDR packages. I believe `libuhd` should be called `uhd` and packages that provide GNU Radio blocks should be named `gr-name` instead of `gnuradio-name` (this affects `gnuradio-{fcdproplus,iqbal,osmosdr}`).
Can we adjust the naming? What do you think?
Thank you, Filipe Laíns
Sorry, my bad.
Regarding uhd, that's what Debian does, not us. uhd is the upstream name and we should honor it. If you want examples just look at [1], from a quick browse I wasn't able to find any instances of packages where we add the lib prefix.
Regarding GNU Radio blocks, it more of a grey area so I understand and respect your position. My reasoning is that the gr- prefix comes from the upstream, and AFAIK everybody else on earth uses it. When I started using Arch it was a bit confusing why the packages had different names, especially for a distribution that tries to keep as close to the upstream as possible. Do you think it would make sense to ask the GNU Radio guys what they think? Either way, it's ultimately your call. But if you don't want to rename it could we add the gr- prefixed name to provides/conflicts?
Just some other unrelated things, I am bringing a few more SDR packages to Arch. I just pushed the necessary bits for Adalm-Pluto support, I am working on srsLTE (actually, almost finished, just waiting for some replies from the upstream) and I want to get some misc GNU Radio blocks. If you want to co-maintain something just drop an email or contact me on irc. Also, I currently own a LimeSDR, Adalm-Pluto, HackRF and rtl-sdr, so if you need any testing please let me know :)
[1] https://www.archlinux.org/packages/?q=library
Thank you, Filipe Laíns
[2020-06-04 23:03:23 +0100] Filipe Laíns via arch-dev-public:
1) Rename libuhd to uhd 2) Use the gr- prefix instead of gnuradio- for GNURadio[2] blocks
Your proposed changes indeed seem the correct thing to do, but Kyle appears to have done a good job maintaining those packages over the years. Do you really think it is worth bypassing his decision using a community vote for something of almost no consequence? If we are to work together, we must sometimes learn to accept others' decisions we don't 100% agree with... Cheers. -- Gaetan
On Thu, 2020-06-04 at 22:43 -1000, Gaetan Bisson via arch-dev-public wrote:
[2020-06-04 23:03:23 +0100] Filipe Laíns via arch-dev-public:
1) Rename libuhd to uhd 2) Use the gr- prefix instead of gnuradio- for GNURadio[2] blocks
Your proposed changes indeed seem the correct thing to do, but Kyle appears to have done a good job maintaining those packages over the years. Do you really think it is worth bypassing his decision using a community vote for something of almost no consequence?
Hi Gaetan, My main concern here is that it is not as simple as it just being Kyle's decision, it sets a precedent. I believe the naming is incorrect, and as such, should be fixed. I have tried initiating a conversation with the maintainer but with that didn't result in anything. I really don't want to step in anyone's toes, I have postponed this email as much as I could. Giving the lack of the reply from Kyle, one can only assume he does not care that much about the issue. I am fine with waiting one or two weeks before taking action to make sure he has time to reply, if there are no objections. I have delayed bringing new GNURadio blocks to [community] due to the naming issue. I would like to have this resolved soon.
If we are to work together, we must sometimes learn to accept others' decisions we don't 100% agree with...
All I am trying to do is work together, but failing. As I said above, this decision affects more than Kyle's packages. Nobody is denying him of him opinion or decision rights, he is free to speak up at any time. I would be very happy to have a discussion with him about the issue :) Cheers, Filipe Laíns
On 6/5/20 9:04 AM, Filipe Laíns via arch-dev-public wrote:
My main concern here is that it is not as simple as it just being Kyle's decision, it sets a precedent. I believe the naming is incorrect, and as such, should be fixed. I have tried initiating a conversation with the maintainer but with that didn't result in anything.
It did result in something: he said "no".
I really don't want to step in anyone's toes, I have postponed this email as much as I could. Giving the lack of the reply from Kyle, one can only assume he does not care that much about the issue. I am fine with waiting one or two weeks before taking action to make sure he has time to reply, if there are no objections.
"I don't agree with this, it fails to be memorable and using the upstream shortname is confusing and does a disservice to users" sure sounds like he objects to me. -- Eli Schwartz Bug Wrangler and Trusted User
On Fri, 2020-06-05 at 10:19 -0400, Eli Schwartz via arch-dev-public wrote:
On 6/5/20 9:04 AM, Filipe Laíns via arch-dev-public wrote:
My main concern here is that it is not as simple as it just being Kyle's decision, it sets a precedent. I believe the naming is incorrect, and as such, should be fixed. I have tried initiating a conversation with the maintainer but with that didn't result in anything.
It did result in something: he said "no".
I really don't want to step in anyone's toes, I have postponed this email as much as I could. Giving the lack of the reply from Kyle, one can only assume he does not care that much about the issue. I am fine with waiting one or two weeks before taking action to make sure he has time to reply, if there are no objections.
"I don't agree with this, it fails to be memorable and using the upstream shortname is confusing and does a disservice to users" sure sounds like he objects to me.
Hi Eli, Sorry, I wasn't clear, my bad. No consensus came from my attempt at contacting him. And there was no discussion, it was one sided, so I feel like this issue is not resolved. There are still relevant points that I want to see addressed. Cheers, Filipe Laíns
[2020-06-05 15:30:54 +0100] Filipe Laíns via arch-dev-public:
No consensus came from my attempt at contacting him. And there was no discussion, it was one sided, so I feel like this issue is not resolved. There are still relevant points that I want to see addressed.
It looks to me like Kyle answered your questions and then had better things to do than continue debating naming conventions, especially as the only kind of "solution" you appear to seek is compliance with your demands. But if you do not accept that a consensus is emerging from replies to your question by Kyle, Eli and myself, do you wish to call for a vote? Cheers. -- Gaetan
participants (3)
-
Eli Schwartz
-
Filipe Laíns
-
Gaetan Bisson