[Feature]: split armbian-firmware into smaller packages
What happened?
$ du -shx /lib/firmware/ ; du -shx /lib/firmware/qcom/
280M /lib/firmware/
180M /lib/firmware/qcom/
As you can see above, even the "minimal" armbian-firmware package is already close to a whopping 300 MB in installed size. More than two-thirds of that is from qcom firmware. It would be great to split the current package into armbian-firmware and armbian-firmware-qcom. Naming could be discussed.
Armbian as usual is cooking up its own magic when compiling its packages 👎
https://github.com/armbian/build/blob/main/lib/functions/artifacts/artifact-firmware.sh https://github.com/armbian/build/blob/main/lib/functions/compilation/packages/firmware-deb.sh
Maybe this would be a good time to do away with that and use straight debian tooling like dpkg-buildpackage and friends. But if not, simply splitting the big package into smaller ones would already be great.
How to reproduce?
$ du -shx /lib/firmware/ ; du -shx /lib/firmware/qcom/
280M /lib/firmware/
180M /lib/firmware/qcom/
Branch
main (main development branch)
On which host OS are you running the build script and observing this problem?
Ubuntu 24.04 Noble
Code of Conduct
- [x] I agree to follow this project's Code of Conduct
Jira ticket: AR-2727
I will add here that I think a general discussion of what the goals/purpose of having armbian-firmware (and armbian-firmware-full).
From my perspective it has become a dumping ground for firmware. There is no record of why a particular firmware is installed in this package. I suspect there are a number of firmwares that are obsolete and no longer needed (ie. for boards that are no longer are supported), but how would anyone know?
I believe the purpose was to have a slimmed down firmware package (vs. the mainline firmware package) that supported the hardware found on boards we support. But with all the csc boards that may no longer make sense to include everything for every board we support or ever have supported.
Also there is a lot of confusion among users of Armbian around this topic too. So they go and purchase a USB wifi dongle that is supported by mainline linux and it doesn't work on Armbian because they on Armbian need to install armbian-firmware-full (which would have those other non-board specific firmwares). But how does a user know this?
Now we don't have to solve all of these issues, but if we are going to invest some effort in this area, at least some of the big picture items should be thought about (maybe there is some low hanging items that can easily be improved).
And it certainly seems the qcom stuff is an area for significant improvement.
@SteeManMI good points
What are common usage scenarios where users might end up needing to install armbian-firmare-full (or upstream linux-firware)? You already mentioned USB WiFi dongles. Other scenarios? The tradeoffs we need to balance here are installed size vs. user convenience.
As such, I guess we need to go through the biggest directories and files and inspect "git log" to figure out why a file was added and possibly by who and when.