Package RTLSDR as .deb and .rpm

[svavassori]

Hello,

I found your project matching pretty well my needs (monitoring multiple AM frequencies), however installation steps require to compile the source code to create the binary and then start to use it.

I was wondering if you will be open to consider packaging the binary (e.g. .deb, .rpm, tar.gz or even as docker image) for some architecture (x86, amd64, arm64...) and made them a available as artifacts "ready to use", so that to install it would be as simple as apt-get install ./rtlsdr-airband-x.y.z.deb. I saw there has been a previous attempt in 2019 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926921 but it didn't get too much attention.

My idea was to contribute with PRs by using GitHub actions/workflows, but I wanted first to check with you if there are any downsides or difficulties that I haven't thought at.

Regards,
Sergio

[charlie-foxtrot]

I don't have any objection to building artifacts and including them in the GitHub release, but I'm not sure how many different versions would need to be generated.

GitHub provides runners for x86_64 but nothing for arm. There is a way to connect your own runner(s) and I was planning to do this once I get my hands on a pi3 (see #379). This would cover linux arm but not apple silicon.

In addition to the different architectures there are a several compile options (enable / disable librtlsdr, mirisdr, soapysdr) and compile flags (-DPLATFORM settings).

Maybe there is some minimal set of configurations that would provide some value and other would continue to compile from source.

[svavassori]

I see: the configurable options expand a lot the possible combinations.

What do you think starting with x68_64, enabling librtlsdr, mirisdr, soapysdr and leaving the compile flags -DPLATFORM=default as "most-used" configuration?

Are there any performance penalties by enabling also NFM?

[feelingwalnut]

I would think it simpler to write a shell script based installer that automates the compile. Prompting you in shell to select the desired options with numbers.
Install item [XX]
1 yes
2 no (default)

But compiling this is simple and fast, is it worth the effort to write an installer or precompile a deb?

If the end user is only capable of clicking on an installer or a GUI dpkg interface, will they be capable of writing their own config file?

[svavassori]

I know that this is relatively simple to compile, but it isn't just about how complex compilation is or "dumb" users that know only to click on a GUI. Instead it is about to uncouple the executable creation from the use of it.

To compile you need to install development dependencies but then, most of them aren't used anymore once you have the binary, because they aren't runtime dependencies, so to keep your system clean you should remove them (or compile it in an isolated enviromnent).
Another point to consider is the build toolchain: in this case it is easy because it is written in C/C++ and all Linux distributions have the C/C++ compiler installed by default, but what about other platforms or if it would have been written in Go, Rust, Zig, Haskel or OCaml?

These are two of the main reasons why almost all Linux distributions use pre-compiled packages to distribute software instead of raw sources (excluding Gentoo of course :-) )

[feelingwalnut]

very valid point. i hate crumbs laying around my filesystem, expecially when you purge something and it leaves its trash behind.
i also hate when something tells me i need 15 things when it'll actually function properly without 10 of them.

[dranch]

Getting pre-built .deb packages will always help both newbies and people trying to manage complex dependencies

[feelingwalnut]

I personally think there is always room to improve. But the wiki is nearly copy-pasteable as far as compiling goes, aside from the options.
The dependencies are also quite clear.

Personally an appimage with a GUI would be cool, but then we have init or systemd running on boot as CLI as well...

[svavassori]

@charlie-foxtrot

I'm progressing with the packaging but I have encounter a doubt about naming: I called the package rtlsdr-airband after the project name (e.g. rtlsdr-airband_0.1.16_amd64.deb ) but then I noticed that the executable is named rtl_airband.

Should the package be named rtl_airband or it would make more sense renaming the executable rtlsdt-airband? (i.e. via symlink to preserve compatibility)

[charlie-foxtrot]

Let’s use the executable name rtl_airband