d/control: Use Recommends on hexagon-dsp-binaries

[lool]

Use a Recommends for the fastrpc-support dep on hexagon-dsp-binaries
instead of a Depends. This notably allows picking a particular platform
or bringing one's own firmware.

[basak-qcom]

Hi!

I appreciate the dependency is broken at the moment. But we do have working hexagon-dsp-binaries packages available at deb.debusine.debian.net/debian/r-rbasak-qcom-hexagon-stack-2/ at least, pending a NEW review to get this fixed in unstable. I also intend to make this available in our apt overlay (so more "official" than a personal space). Will that do for now? Otherwise we'll only be flipping this back as soon as hexagon-dsp-binaries is properly resolved in unstable. I'm reluctant because of that and because I think a Depends is strictly correct, but if you feel strongly that we should upload to unstable now to change this with a Recommends, I'm open to that.

[lool]

I don't think this is a transient topic, the two reasons that make me challenge the Depends:

1. apt-cache rdepends firmware-linux, firmware-linux-nonfree, firmware-qcom-soc, firmware-atheros will show that we never pull firmware implicitly; I think it's over constraining, and a working system is achieved by some installer pulling the bits that are relevant

2. hexagon-dsp-binaries is split in per-platform binary packages to avoid bloat; if we use a depends on a meta-package that depends on all binary packages, we defeat this whole approach

I could see why a Recommends rather than a Suggests could be warranted since most people pulling in fastrpc-support are likely to want hexagon-dsp-binaries, and it might not be installed for them by an installer yet, but I think a Depends is pushing the constraints too far.

If there's a hard dependency on a script/data file from h-d-b, then let's look at that and split it out in some -common package or change the design to avoid this.

[basak-qcom]

Existing discussion on the dependency structure here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1126262

That includes a solution for your per-platform binary split package concern, but that's not implemented yet and would still use a Depends (but on a virtual package) from the fastrpc-support side.

Maybe we should continue discussion there?

[lool]

we discussed this with Robie and Dmitry (hexagon-dsp-binaries); Dmitry doesn't care about Depends vs Recommends, and we all also want a Provides: hexagon-dsp-any to be able to have deps like hexagon-dsp-binaries-all | hexagon-dsp-binaries-any.

[lool]

I tried to install fastrpc-support from an Ubuntu resolute install; it's currently not published because the dependency is breaking through components:

another reason to demote to a Recommends IMO

https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses.html

[basak-qcom]

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1130492 prompted me to look again at this. I'm not used to working outside main in Debian so hadn't thought about this. Debian policy 2.2.1 bans a Recommends, too. So does fastrpc need to move to contrib, or do we need to drop to Suggests and leave it to the user to resolve? I'm not keen on this since this is an implementation detail I don't expect users to know about.

[lool]

Yeah, I spotted the same thing in britney in Ubuntu preventing the package from migrating from resolute-proposed

IIUC, it's theoretically possible to write free firmware or could be in the future. Perhaps for Debian and Ubuntu, people can install free software but mostly useless fastrpc by default, and there's a command / README in the package explaining that:

• firmware has to be installed / provided
• that one can install the one from Debian/Ubuntu with these components and this package name
• perhaps even a command to pick the right firmware for one's platform rather than installing all of them

[basak-qcom]

On Mon, Mar 16, 2026 at 07:56:12AM -0700, Loïc Minier wrote: IIUC, it's theoretically possible to write free firmware or could be in the future.

That seems very theoretical. This could apply to all software in contrib - it's theoretically possible to write Free Software replacements for their dependencies, and therefore they should be in main instead but without dependencies declared? What if we just moved fastrpc packaging into contrib, since _at the moment_ it is useless without non free blobs? If that situation ever changed and free dependencies got packaged, the fastrpc package could move back to main. Robie

[lool]

On Mon, Mar 16, 2026 at 07:56:12AM -0700, Loïc Minier wrote: IIUC, it's theoretically possible to write free firmware or could be in the future.
That seems very theoretical. This could apply to all software in contrib - it's theoretically possible to write Free Software replacements for their dependencies, and therefore they should be in main instead but without dependencies declared? What if we just moved fastrpc packaging into contrib, since at the moment it is useless without non free blobs? If that situation ever changed and free dependencies got packaged, the fastrpc package could move back to main. Robie

It is somewhat theoretical, but there's hexagon support in LLVM

Sure; I'm ok with contrib, seems more honest

[basak-qcom]

On Mon, Mar 16, 2026 at 10:27:34AM -0700, Loïc Minier wrote: Sure; I'm ok with contrib, seems more honest

OK. I'll plan to move this to contrib then. One more clarification please. With Depends in contrib, or with Recommends in contrib? This would be on hexagon-dsp-binaries-any in the end, so I think Depends would then address your previous concerns?

[lool]

Personal perspective: I think it's slightly more elegant to not overconstraint people/systems with Depends and use Recommends for these use cases. Installers / package managers should do the right thing to bring the right mix of packages, Depends are overly strict IMO.

[lool]

Other things to consider that I didn't mention here:

• we've considered fastrpc for the cdsp, and firmware binaries in hexagon-dsp-binaries, but it can also speak with adsp, sdsp and other dsps
• fastrpc is an opensource RPC mechanism that could be used for anything in theory, not just hexagon DSPs

but despite the above, I believe it's currently only useful with firmware that are only packaged in non-free.

[basak-qcom]

Closing: superseded by #29.