[arch-dev-public] SDR package naming

Thu Jun 4 22:03:23 UTC 2020

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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20200604/1c462bff/attachment.sig>