From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49693) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c9Ywc-0005zI-4m for qemu-devel@nongnu.org; Wed, 23 Nov 2016 09:54:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c9YwY-0000Vx-SW for qemu-devel@nongnu.org; Wed, 23 Nov 2016 09:54:42 -0500 Received: from mx1.redhat.com ([209.132.183.28]:35146) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c9YwY-0000U2-Lg for qemu-devel@nongnu.org; Wed, 23 Nov 2016 09:54:38 -0500 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id F085C7AE97 for ; Wed, 23 Nov 2016 14:54:36 +0000 (UTC) Date: Wed, 23 Nov 2016 14:54:33 +0000 From: "Daniel P. Berrange" Message-ID: <20161123145433.GH6750@redhat.com> Reply-To: "Daniel P. Berrange" References: <1479907484-4988-1-git-send-email-kraxel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1479907484-4988-1-git-send-email-kraxel@redhat.com> Subject: Re: [Qemu-devel] [RfC PATCH 0/3] edk2: add efi firmware builds List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: qemu-devel@nongnu.org On Wed, Nov 23, 2016 at 02:24:41PM +0100, Gerd Hoffmann wrote: > Hi, > > This patch series adds a edk2 submodule in roms, also a build script > and makefile rules to build ovmf and arm firmware. > > The build script creates per-arch subdirs in pc-bios and places the > firmware files there. They are not exactly small: > > kraxel@nilsson ~/projects/qemu (work/edk2)# du -s -h pc-bios/edk2-* > 2,8M pc-bios/edk2-aarch64 > 2,8M pc-bios/edk2-arm > 2,1M pc-bios/edk2-i386 > 2,1M pc-bios/edk2-x86_64 > > So, the question is how we wanna go forward with this. Adding the > submodule and rules is a no-brainer I think. But what about the > binaries, which sum up to roughly 10M? Ship them all? Ship the > 64bit archs only, given that efi never really took off on i386 > and arm? > > Other comments? Should we think about our policy for distributing & shipping ROMS more generally ? Most distros will actively strip out the ROMs that we ship in the QEMU tar.gz releases, and rebuild them from pristine source in order to ensure they're fully complying with licensing requirements wrt "full & corresponding source". So should we consider actually shipping 2 tar.gz files for QEMU releases. One minimal qemu-x.y.z.tar.gz that only contains pristine QEMU source with no pre-built artifacts, and a second qemu-full-x.y.z.tar.gz that contains the QEMU source, plus an arbitrary number of pre-built blobs. Alternatively, instead of a qemu-full-x.y.z.tar.gz, we could just have a qemu-roms-x.y.z.tar.gz bundle which only contained the ROMs, which users would use in combination with the other releae. Vendors would use the minimal release, while users who just want to build their own QEMU with least effort would use the full release tar.gz If we had some split like this, then I think we would not have to really worry about the fact that the ROMs will get quite large as the size would only impact people wanting to download the full release. In terms of GIT, we could likewise make the binary ROMS live in a submodule, so we don't bloat the main GIT repo, but I don't think that's so critical Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|