On Fri, 17 Oct 2025 at 13:53, BALATON Zoltan <[email protected]> wrote: > > On Fri, 17 Oct 2025, Peter Maydell wrote: > > Release tarballs > > ---------------- > > > > - Our release tarballs are quite large, and 85% of them is just the > > source of EDK2 which we include as the corresponding source for the > > EDK2 ROM blobs. This seems a bit silly, since most consumers of the > > tarball are either: > > - downstream distros who will want to build their own ROM blobs > > from the real upstream sources > > - end users who don't want to build the ROM blobs at all > > > > - We could perhaps usefully split the tarballs so that the ROM sources > > and the ROM blobs are in their own tarballs and only people who need > > them download them. > > Wouldn't this be solved by splitting off the EDK2 version QEMU needs into > a separate project (something like qemu-edk2) and make that a separate > dependency?
EDK2 is only special here because it happens to be huge. If we're going to not have "one single huge tarball" then the question is "what should the split be?". > > - Relatedly, it would be nice for the ROM blobs to be trivially > > regenerable by anybody, rather than the current ad-hoc "some > > trusted person builds a binary locally and we commit it to git" > > setup. This should be much easier in these days of containers than > > it was when we first started committing compiled blobs to git. > > Having blobs is a big conveniece that would be preferable to keep as most > of the time people don't need to rebuild blobs if they just want to run a > machine and even if changing a machine they don't need to touch the > firmware so it's only a few people who may want to install cross compilers > or a container to rebuild blobs and it would be nice to save others that > hassle. Yeah. I think we would still commit the compiled blobs to git; this bullet point is more about "make it more reproducible so anybody, or perhaps our CI system in an automated job, can create the blobs to be committed". One idea I think that was suggested in the meeting was that we could make our build system say "if the blobs aren't present locally, download the blob tarball the way we do for various other dependencies we might download at build time". That would make things "just work" for most people while maintaining the separation of blobs and blob-sources from QEMU's actual sources. > > - However, nothing is fundamentally broken with our current setup, so > > unless anybody who really wants to do this work is going to step > > up we probably won't do anything ;-) But also notice this part -- if anybody wants to tackle the problem they get to define it and also do requirements collection... -- PMM
