07.03.2013 15:56, Gerd Hoffmann wrote:
Just a note, or an "alternative opinion", so to say. In Debian, we have a social contract which, among other things, ensures that the binaries you, as a user, get, comes with source which you can modify on the system you installed. This requires, for example, that all binaries shipped are actually built from the corresponding source, and that no blobs from whatever other sources are used, ever.
That is perfectly fine. How to you handle ppc firmware for x86 hosts btw? Build on ppc buildhost and ship as noarch package? Or do you do cross compiler builds, so that users can patch+rebuild it on their x86 host too?
"Foreign" firmware handling is an unsolved issue. Yes, basically, it is built on the corresponding build machine (eg, openbios-ppc is built on a ppc machine) and shipped as "noarch" package. The same is for X86 seabios/vgabios/etc stuff actually.
So technically this is a violation in some way. However, that same ppc firmware actually can be rebuilt in a (qemu) virtual machine with the same debian release installed.
That's why I say it is basically unsolved issue -- the "solution" isn't actuall a solution but a workaround instead.
For added "fun", currently we ship optionroms from qemu in seabios source package, exactly because of this reason - seabios is what gets built on x86 only and is distributed on as "noarch" binary, while qemu is built on all architectures.
And for another fun, we've several broken qemu architectures in Debian at the moment -- s390 and ppc64 are missing firmwares exactly because of the difficulties building them, despite the fact they're shipping in upstream qemu tarball.
We don't even ship any upstream blobs in the debian qemu _source_ package: we repack upstream qemu.tar.gz by removing these blobs.
That's a bit over the top for my taste as the release tarballs include both source and blobs.
Yes this is a bit extremistic, so to say. But this is the same base principle of Debian: we should ensure and demonstrate it all is buildable. Just mere presence of a blob in a tarball is already suspicious :)
Although it might be the debian release is just a bit too old for that, not fully sure with which release anthony started to include the firmware submodules, might be it was after 1.1
Nope, qemu started including sources before that. But it doesn't matter really, it is just the way how debian works, nothing to do with qemu really. Especially since most of these submodules are already packaged in Debian separately (be it because the qemu needs or due to other means).
Thanks,
/mjt