Hi! I'm a DD intending to sponsor hexagon-dsp-binaries for Dmitry once we've settled on the outstanding issues.
On Sat, Aug 23, 2025 at 12:09:57AM +0300, Dmitry Baryshkov wrote: > The binaries for the DSP must exactly match the version of DSP > firmware (provided by the firmware-qcom-soc package). I think there are a few different options for dealing with this, none of which are great: 0) We do nothing. When firmware-nonfree updates the relevant DSP firmware, hexagon-dsp-binaries will stop working until it is also updated. 1) hexagon-dsp-binaries is upstreamed into linux-firmware itself, making it straightforward to always update all the binaries at the same time. But Dmitry also tells me that these (non-free) hexagon-dsp-binaries are *not* firmware (whatever "firmware" actually means!) and if upstream agree then presumably they wouldn't consider it acceptable to include there. 2) hexagon-dsp-binaries depends on an exact (enough) version of firmware-qcom-soc. When firmware-nonfree is updated, it will not be able to migrate to testing until hexagon-dsp-binaries is also updated. In the common case where DSP firmware has *not* been updated, this would require an otherwise-unchanged upload of hexagon-dsp-binaries that only bumps the "required" firmware-qcom-soc version. In the less common case that the DSP firmware *has* been updated, it would be a proper and necessary update of hexagon-dsp-binaries that also bumps the "actual" required firmware-qcom-soc version. I'm less in favour of this approach because I don't wish to burden the firmware-nonfree maintainers with waiting on hexagon-dsp-binaries maintainers (or otherwise taking some upload action on a different package) before their package can migrate to testing, especially in that common case of DSP binaries not having been updated at all. And users will have to keep re-downloading unchanged hexagon-dsp-binaries updates every time firmware-nonfree is updated. It seems like this would run counter to the concept of package versioning entirely. 3) firmware-qcom-soc Provides a virtual package at some DSP ABI version, and hexagon-dsp-binaries depends on that. Then firmware-nonfree will require no special treatment and will be unaffected *unless* the DSP firmware is changed, in which case the DSP ABI version needs to be bumped in the appropriate firmware-nonfree upload instead. In this case we need to ensure that the DSP binaries are not updated unless the ABI version *is* bumped, which would be very easy to do since that's the normal workflow. Appropriate tooling can help with that and also make this very easy for the firmware-nonfree maintainers to manage. I've demonstrated this here: https://salsa.debian.org/kernel-team/firmware-nonfree/-/merge_requests/128 Currently I favour the third option. I think the Provides would accurately represent the reality of the hardware behaviour having an effective ABI to userspace. Package updates would only be required when actually necessary under this reality. And I think I've essentially eliminated the burden to firmware-nonfree maintainers in my proposed tooling. I welcome any other opinions and suggestions. Is there a cleaner way to do this entirely? Thanks, Robie
