Arch Linux

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

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.

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.

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.