Comment 4 for bug 1895137

> Just to clarify, is this suggesting it should install cleanly on non-pi
> arm hardware, but *then* refuse to work (with some appropriate error
> message) or should it refuse to install at all e.g. at dependency
> resolution time. I'd love to implement the latter but I've no idea how
> (is there such a thing as a package that's only available to pi
> images?). The former is rather more complex as it means fixing how
> linux-firmware-raspi2 installs its boot firmware (which is something
> that's been sat on my TODO list for yonks, but it means some rather
> invasive flash-kernel changes where we're already carrying a huge
> delta).

Either way works, but I'm not aware of any differentiation beyond
architecture that you can use.
And since arm64/armhf can be so many different things I'd ask to get
something into e.g. postinst that detects if it runs on the right HW
and if it doesn't skips the rest.
That way the binaries are available for evaluation but have no function.
If there are other active bits/hooks, then yes you'd want to disable
them as well in that case.

We've had similar cases where a package makes no sense in a container context.
But making it fail gracefully avoided people getting stuck with broken
packages which can be a big problem especially for less experienced
users.