pkgsrc-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: ham/gnuradio-monolithic (Re: diff from 2023-04-11 11:36 to 2023-04-13 11:25

Makoto Fujiwara <> writes:

> For ham/gnuradio, 
> we have following packages for now.
> 1. ham/gnuradio-core
> 2. ham/gnuradio-*
> 3. meta-pkgs/gnuradio
>   (this 3. is equal to 1 + 2)
> 4. wip/gnuradio-monolithic
>   this is (almost, or exactly) the same as 3, hopefully
> Upstream organization is problably 4.

Yes, but that's source code.  I think it's a bug to have the gui stuff
in the same repo, as any packaging system would want to build it separately.

> FreeBSD may have the same shape as 4.

Agreed that FreeBSD looks like 4, but also the FreeBSD package (port)
depends on, among others:

  py39-qt5-pyqt>=5.15.9 : devel/py-qt5-pyqt@py39

Debian has:

  gnuradio-dev/stable,now amd64 [installed,automatic]
  gnuradio-doc/stable all
  gnuradio/stable,now amd64 [installed,automatic]
  libgnuradio-analog3.8.2/stable,now amd64 [installed,automatic]
  libgnuradio-audio3.8.2/stable,now amd64 [installed,automatic]
  libgnuradio-blocks3.8.2/stable,now amd64 [installed,automatic]
  libgnuradio-channels3.8.2/stable,now amd64 [installed,automatic]
  libgnuradio-dab3.8.0/stable 0.4-2+b5 amd64
  libgnuradio-digital3.8.2/stable,now amd64 [installed,automatic]
  libgnuradio-dtv3.8.2/stable,now amd64 [installed,automatic]
  libgnuradio-fcdproplus3.8.0/stable,now 3.8~20190817-3+b5 amd64 [installed,automatic]
  libgnuradio-fec3.8.2/stable,now amd64 [installed,automatic]
  libgnuradio-fft3.8.2/stable,now amd64 [installed,automatic]
  libgnuradio-filter3.8.2/stable,now amd64 [installed,automatic]
  libgnuradio-fosphor3.8.0/stable,now 3.8~2.2d4fe78-1+b6 amd64 [installed,automatic]
  libgnuradio-hpsdr1.2.1/stable 1.2.1-2+b3 amd64
  libgnuradio-iio1/stable 0.3-9+b4 amd64
  libgnuradio-iqbalance3.8.0/stable,now 0.38-4+b5 amd64 [installed,automatic]
  libgnuradio-limesdr3.0.1/stable 3.0.1-2+b6 amd64
  libgnuradio-osmosdr0.2.0/stable,now 0.2.2-1+b4 amd64 [installed,automatic]
  libgnuradio-pmt3.8.2/stable,now amd64 [installed,automatic]
  libgnuradio-qtgui3.8.2/stable,now amd64 [installed,automatic]
  libgnuradio-radar1.0.0/stable amd64
  libgnuradio-rds1/stable amd64
  libgnuradio-runtime3.8.2/stable,now amd64 [installed,automatic]
  libgnuradio-satellites3.5.1/stable 3.5.1-2+b2 amd64
  libgnuradio-soapy2.1.3/stable 2.1.3-2 amd64
  libgnuradio-trellis3.8.2/stable,now amd64 [installed,automatic]
  libgnuradio-uhd3.8.2/stable,now amd64 [installed,automatic]
  libgnuradio-video-sdl3.8.2/stable,now amd64 [installed,automatic]
  libgnuradio-vocoder3.8.2/stable,now amd64 [installed,automatic]
  libgnuradio-wavelet3.8.2/stable,now amd64 [installed,automatic]
  libgnuradio-zeromq3.8.2/stable,now amd64 [installed,automatic]

and one can see libgnuradio-qtgui separate.

> The reason of splitting into like 1 + 2, was probably based on
> my historical modification, see the thread starting at:
> Now maintaining PLIST for 1 + 2 becomes a little bit time consuming.

I would say the reason to split is that of the various gnuradio-foo
modules, some of them have really piggy dependencies (qt5), and it's
reasonable to want to run parts of gnuradio on machines without qt5.
gnuradio is not fundamentally a gui program.

There are also libs for various radios.  Those don't seem so bad to drag
along when not wanted as they don't seem so hard to build or big, but
still they are unnecessary for most people.

> I would propose either
> A. - Remove 1, 2, 3  (imediately)
>    - Put 4 with a name PKGNAME and directory "gnuradio"
> B. - put 4 with a name PKGNAME and directory "gnuradio-monolithic"
>    - Then some time later,
>       remove 1,2,3,
>       rename gnuradio-monolithic to gnuradio
>       (directory and PKGNAME)
> (or)
> C. - keep current module organization

I would lean to "don't do B".

I think the monolithic is too big if it includes qt.

I just kicked off a build of gnuradio-monolithic (on a machine which has
qt5 anyway) and will see what the dependencies are.

So I prefer C, as "can be installed when qt is unbearable" (RPI1 with
0.5G RAM?) is to me a very important property.

Home | Main Index | Thread Index | Old Index