On 7 March 2013 23:56, Gerd Hoffmann kraxel@redhat.com wrote:
Peter Maydell wrote:
In general having blobs in our allegedly source tarball is pretty ugly. Either it's a source release or it isn't. We can do a release-of-blobs tarball too if we want, but it doesn't need to be in the source tarball
This is easily doable, just an update to scripts/make-release to spew two tarballs (one source, one blobs).
We probably want update the build process to build the blobs by default (if the compilers needed are installed). Blueswirl started that already for sparc firmware I think.
Earlier in this thread it's been stated that this often produces subtly broken blobs...
and it doesn't need to be in git either IMHO.
That one is a bit more tricky. The big advantage git has here is that the update of a blob is not different from other updates. It is just a pull request. Keeping source+binaries in sync is easy too: we can update submodule hash + blobs with a single git commit.
You could put the sources for the binary blobs in their own git repo, and then have the blobs in that git repo rather than qemu mainline.
-- PMM