Re: [PATCH v2 for-8.0 0/5] scripts/make-release: Decrease size of the release tarballs

[Daniel P . Berrangé]

On Wed, Nov 30, 2022 at 11:49:50AM +0100, Thomas Huth wrote:
> On 28/11/2022 18.04, Daniel P. Berrangé wrote:
> > On Mon, Nov 28, 2022 at 10:25:50AM +0100, Thomas Huth wrote:
> > > Our release tarballs are huge - qemu-7.2.0-rc2.tar.xz has a size of 116
> > > MiB. If you look at the contents, approx. 80% of the size is used for the
> > > firmware sources that we ship along to provide the sources for the ROM
> > > binaries. This feels very wrong, why do we urge users to download such
> > > huge tarballs while 99.9% of them never will rebuilt the firmware sources?
> > > We were also struggeling a bit in the past already with server load and
> > > costs, so we should really try to decrease the size of our release 
> > > tarballs
> > > to a saner level.
> > 
> > The main reason for shipping the source in the tarball was to
> > guarantee license compliance for anyone who is distributing
> > qemu release tarballs, including ourselves.
> > 
> > Splitting off the firmware source, but not the firmware binaries,
> > means people are now at risk of not complying with the license
> > but failing to provide complete and corresponding source.
> > 
> > Technically the license requirement is only critical for GPL
> > licenses ROMs, but as good practice we do it for all our ROMs.
> > 
> > > So let's split the firmware sources into a separate tarball to decrease
> > > the size of the main QEMU sources tarball a lot (which should help us
> > > to safe a lot of traffic on the server).
> > 
> > With my distro maintainer hat I would rather QEMU ship neither the
> > ROM source, nor the ROM binaries.
> > 
> > Still the binaries are convenient for people doing their own QEMU
> > builds from source.
> > 
> > How about shipping two distinct options:
> > 
> >    qemu-x.y.z.tar.xz          (QEMU source only)
> >    qemu-bundled-x.y.z.tar.xz  (QEMU source + bundled ROM binaries + ROM 
> > sources)
> > 
> > though I'm not sure how much of an impact that will have on the download
> > traffic - depends what is causing the traffic.
> > 
> > Another option is
> > 
> >    qemu-x.y.z.tar.xz        (QEMU source only)
> >    qemu-roms-x.y.z.tar.xz   (bundled ROM binaries + ROM sources)
> > 
> > though this is slightly more inconvenient for users, and there's the
> > risk they'll use new QEMU with old ROMs.
> 
> Maybe that would work for distros, but I don't think that these are good
> options for the average users who just want to download and recompile the
> latest version of QEMU on their own.
> I assume that most users don't have an environment with cross-compilers or
> for running things in a container, so I think they still want to use the
> pre-built binaries. Thus, if you bundle the binaries along with their
> sources, people will still continue to download the big tarball and we
> haven't gained anything.
> 
> So do you really really think shipping the binaries in the main tarball is a
> problem? Honestly, it's not a problem for us as long as we publish both
> tarballs together - and if someone wants to mirror the main tarball to their
> webserver and fails to mirror the rom-sources tarball, too, it's their
> fault, not ours.

I think we would be contributing to mistakes by providing a tarball
that contains a mixture of sources and binaries, but not all the
sources for all the binaries. 

> Anyway, what about splitting the binaries into a separate tarball, so we
> would have three tarballs:
> 
>     qemu-x.y.z.tar.xz               (QEMU source only)
>     qemu-roms-x.y.z.tar.xz          (ROM binaries)
>     qemu-roms-sources-x.y.z.tar.xz  (ROM sources)
> 
> That should make it hopefully obvious that the two qemu-roms* tarballs
> belong together. Would that be OK for you?

Yes, I think that's better, as it is cleanly separating the
binaries and sources.

Even bikeshedding a bit more I woud have probably suggested
'qemu-roms-prebuilt-x.y.z.tar.xz' for ROM binaries and
'qemu-roms-x.y.z.tar.xz for the ROM sources, since sources
is the normal tarball content.

The downside is that there's the risk of ROMS not matching
the QEMU version, if people updates to latest qemu tarball
but forgot the corresponding ROMs tarball. Most of the time
a mismatch would not matter, but we should think about if
there is a way to make it easier to diagnose such a
mismatch if only for easier bug triage.

Perhaps the ROMs should install into a versioned subdir
of /usr/share/qemu, instead of the root of it, and the
QEMU binary preferentially look at the versioned subdir
Maybe that's overthinking things though, and we would
suffic to have a /usr/share/qemu/ROM-VERSION.txt file

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|