| 1 |
How important are separately buildable binary blobs? Rather than speak |
| 2 |
in terms of app/foo and app/bar, I'll just come out and say its |
| 3 |
app-emulation/qemu. Due to the nature of the package it relies on |
| 4 |
firmware blobs to emulate certain aspects of the system (e.g. BIOS). |
| 5 |
I've been working on making each of the binary blobs buildable and |
| 6 |
adding them to the tree e.g. |
| 7 |
sys-firmware/ipxe, sys-firmware/seabios, sys-firmware/sgabios, |
| 8 |
sys-firmware/vgabios. Unfortunately QEMU upstream keeps their own |
| 9 |
repos of the various components and for each release builds their own |
| 10 |
and commits it within their repo. They ship with these pre-built blobs |
| 11 |
and that is what they install by default. The result is from the true |
| 12 |
package upstreams there often is not a release that works with QEMU. |
| 13 |
For example, QEMU 1.3.0 requires a git revision of SeaBIOS. |
| 14 |
|
| 15 |
So basically, how important is it to keep supporting these separately |
| 16 |
buildable blobs knowing that it might slow the release of QEMU within |
| 17 |
our own tree. |
| 18 |
|
| 19 |
-- |
| 20 |
Doug Goldstein |
Archives