Community Packages

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#63454 - [gnuradio-companion] move application from gnuradio to gnuradio-compantion package

Attached to Project: Community Packages
Opened by Julian Daube (joposter) - Tuesday, 13 August 2019, 14:15 GMT
Last edited by Kyle Keen (keenerd) - Thursday, 05 September 2019, 10:46 GMT
Task Type General Gripe
Category Packages
Status Closed
Assigned To Kyle Keen (keenerd)
Architecture All
Severity Very Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


While i realize this might be nitpicking, could i at least get a reason why the executable
this package was named after resides in another package (gnuradio in this case)?

When i first installed gnuradio i thought the package was broken, because while gnuradio-companion was
already installed, it just would not start without the deps from gnuradio-companion.

I would not have thought to install a seperate package because the executable was already there.
I don't know how many people this affects but i surely would have looked for a different package otherwise....

Is the gnuradio-companion app needed for something inside of gnuradio's package ?
This task depends upon

Closed by  Kyle Keen (keenerd)
Thursday, 05 September 2019, 10:46 GMT
Reason for closing:  Won't fix
Comment by Julian Daube (joposter) - Tuesday, 13 August 2019, 14:17 GMT
small edit to clarify, by

> [...] because while gnuradio-companion was already installed, [...]

i meant the executable was already there, NOT that the package was already installed
Comment by Kyle Keen (keenerd) - Monday, 02 September 2019, 14:20 GMT
Gnuradio and GRC are difficult to split.

GRC has had a fairly extensive set of dependencies. (Though this has gotten better with the 3.8 release.)

Pacman has no concept of "optdep that is required for the optional purpose" vs "optdep that is optional for the optional purpose".

Gnuradio is used by a lot of power users, who want flexibility in how it is installed.

GRC is used by a lot of newbies, who just want their rtl-sdr to do the neat stuff.


So there are four options as I see it:

1) A single "stock" gnuradio with nine optdeps of varying degrees of importance. Newbies don't like this. Nine is too many. Besides having to manually install the deps, they need to manually handle when updates change the deps.
2) A single "stock" gnuradio package that has no optdeps, and instead comes with every dep under the sun for GRC. Power users don't like this. They have to rebuild Gnuradio.
3) Two packages: a lightweight CLI-only gnuradio with GRC components split into a GRC package. Maintainers don't like this. It is a lot of work, and unsupported upstream, and likely to break. Power users aren't entirely happy either, since GRC is no longer customizable.
4) Two packages: a "stock" gnuradio package and a "skeleton" GRC package that handles all of the dependencies. Power users like this: they can install gnuradio and whatever optdeps they want for their purposes. Newbies like this: they can install GRC, and never have to worry about deps. And of course the maintainer likes this too, since it is what I am doing.


From the newbie's perspective, options 2/3/4 are the same. You install one package and everything just works. From the power user's perspective, options 1/4 are the same with 3 almost as good. You get a basic core that can be extended.

Going with 1 or 2 will make some set of people unhappy. Without upstream support, 3 will send me to an early grave. But 3 and 4 are functionally identical until someone like yourself looks under the hood :-)

So beginners can install "gnuradio-companion" to get everything and the kitchen sink, and never have to look under the hood. That is what it is there for. Power users can install "gnuradio", and build on top of that with whatever set of deps they need for their purposes. The occasional person who is becoming a power user gets caught up in "Why is /usr/bin/gnuradio-companion in the gnuradio package?"


I'll leave this open for a while, in case you have any ideas or questions.

Comment by Julian Daube (joposter) - Tuesday, 03 September 2019, 09:19 GMT
Yea i figured 3 would likely be a time consuming process if done "right".
But since i for one am not interested in installing the gnuradio-companion without gnuradio (which is not supported upstream indeed), would it be an okayish compromise to move just the binary to the gnuradio-companion package?

I (personally) was just confused the binary was there (since it cannot run without its dependencies anyway).

As i see it that approach would not break anything (since your usecases assume the pro-user does not need the companion anyway it would actually "shrink" the package),
since both packages are built by the same PKGBUILD it should be trivial to do.

Another advantage (as i see it) would be that pacman -Fo /usr/bin/gnuradio-companion would actually yield gnuradio-companion as a package, not gnuradio.
Comment by Kyle Keen (keenerd) - Tuesday, 03 September 2019, 21:51 GMT
No, I don't feel it would be a compromise. Power users who want a customized GRC lose that ability. This was a greater concern in previous versions, when there was choice of multiple graphical (WX and Qt) backends. Presently you can choose to not use the OpenGL parts, and in the future you'll be able to choose to not use the SDL parts.

The GRC binary is 3KB. The "shrink" is negligible.