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.