Source: hexagon-dsp-binaries Version: 0~20251011-1 Severity: wishlist # The problem I want to fix
A package that requires hexagon-dsp-binaries to function should be able to declare a dependency on it while allowing for the following use cases: 1) A "fat image" generator that generates an image that ships such a package should be able to pull in binaries for all boards (this is already possible). 2) A "thin image" generator that generates an image that ships such a package should be able to pull in binaries for one specific board. 3) A user who doesn't know about the specifics of Debian's package dependency graph should be able to install something that, if it happens to require hexagon-dsp-binaries, automatically causes apt to install something that works. Probably this means that we need to pull in binaries for all boards by default, since the current design of apt and dpkg doesn't support hardware-specific dependencies. Consider for example the upcoming fastrpc-tests package. I think this should depend on the correct parts of hexagon-dsp-binaries, and it should work for all three use cases above. Right now, it depends on the hexagon-dsp-binaries metapackage, which works for cases 1 and 3 above, but not case 2. There is nothing direct to depend upon that would allow case 2 except a very long alternates line that would be difficult to maintain. # Proposal I propose the following. This is deliberately an ideal layout without paying attention to what is already there, to help illustrate what I mean. We can figure out how to get here from there or any other compromises based on the past later. hexagon-dsp-binaries-all: metapackage that pulls in the individual "implementations": Package: hexagon-dsp-binaries-all Depends: hexagon-dsp-binaries-thundercomm-rb3gen2, hexagon-dsp-binaries-thundercomm-rb1, ... hexagon-dsp-binaries-impl: a virtual package Provided by each individual "implementation", eg. hexagon-dsp-binaries-thundercomm-rb3gen2. Package: hexagon-dsp-binaries-thundercomm-rb3gen2 Provides: hexagon-dsp-binaries-impl fastrpc-tests would then: Package: fastrpc-tests Depends: hexagon-dsp-binaries-all | hexagon-dsp-binaries-impl Use cases 1 and 3 would work via the "first alternate" resolution of apt, pulling in all binaries so it'll work. Use case 2 would work via the alternate: the thin image generator would specify for example hexagon-dsp-binaries-thundercomm-rb3gen2, apt would see that and not pull in the others. # A couple of thoughts on dependencies in general ## Direction of dependencies In my ideal world, a Debian user would have a fully free software stack functioning entirely from Debian. Users who have suitable hardware and are willing to accept non-free-firmware should be able to ask apt to install one thing, and the same stack should become hardware accelerated. That one thing should then depend on everything else required. In the traditional linux-firmware model, we might have say an entire wifi stack that might work except that one thing needs to be in /lib/firmware that is hardware dependent. So the user is expected to either install that directly via the correct binary package that they know, or install all of it via a metapackage, or an installer will do that for them. Whichever way, it's one package that then makes everything work. With Hexagon DSP we also need other components such as FastRPC. So I think the one package that makes everything work, and therefore the dependency chain, should be extended such that it comes from that direction. In my example above, that's fastrpc-tests that should pull in the right hexagon-dsp-binaries packages that should pull in firmware-qcom-dsp. For this reason I don't have a strong opinion on the question of Depends vs. Recommends from firmware-qcom-soc to firmware-qcom-dsp. I think the UX should come from the other direction. ## Config file We're going to need to ship 00-hexagon-dsp-binaries.yaml. FastRPC depends on this now. There isn't currently an obvious place to put it. ### Config file approach 1 One approach might be that we put it in hexagon-dsp-binaries-config. Each individual implementation package would then declare a dependency on this package that ships the config file: Package: hexagon-dsp-binaries-thundercomm-rb3gen2 Provides: hexagon-dsp-binaries-impl Depends: hexagon-dsp-binaries-config ### Config file approach 2 An alternative approach could be to split the config file up per-board, and ship the correct one per board. The conf.d/ structure would help with that. If you think it will work and prefer this, we could do that instead and perhaps it'll be simpler. Annoyingly though we'd need to write code to split the upstream file. # Migration path I don't think we should worry about this. hexagon-dsp-binaries first appeared in forky only, it isn't really useable on its own yet, and I think we have very few users who aren't us, if any. Debian makes no commitment for migration paths in testing. As far as I'm aware, it's always been best-effort only. So I think we should rearrange things for the future without being held back by difficulties in enabling automatic migration paths. If anyone is relying on hexagon-dsp-binaries in testing, it should be sufficient just to announce how we have rearranged things so they know what to do for their use case in new arrangement instead. I used hexagon-dsp-binaries-all in my proposal above for clarity. I think this would help users too, so I propose to rename the existing hexagon-dsp-binaries to that. But my proposal will work equally well if we do not.
