qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [qemu-web PATCH] download: Add instructions for MacPort


From: Daniel P . Berrangé
Subject: Re: [Qemu-devel] [qemu-web PATCH] download: Add instructions for MacPorts
Date: Wed, 4 Apr 2018 15:58:03 +0100
User-agent: Mutt/1.9.2 (2017-12-15)

On Wed, Apr 04, 2018 at 04:45:48PM +0200, Paolo Bonzini wrote:
> On 04/04/2018 16:38, Daniel P. Berrangé wrote:
> >>> Actually I believe we should remove those links.  I don't think hosting
> >>> QEMU binaries on mediafire is a good idea.
> >>>
> >>> Paolo
> >> Why not?
> > The source/quality of those binaries is completely opaque. We've no idea who
> > built them, nor what build options were used, nor what/where the 
> > corresponding
> > source is (required for GPL compliance), nor any checksum / signature to
> > validate the binary isn't compromised since build, etc, etc.
> > 
> > Pointing users to those binaries makes it appear QEMU project is blessing
> > them, and so any issues with them directly reflect on QEMU's reputation.
> > 
> > If we're going to link to binaries telling users to download them, we need
> > to be hosting them on qemu.org and have a clearly documented formal process
> > around building & distributing them.
> > 
> > Since both Homebrew & Macports are providing formal bulds though, it looks
> > simpler to just entirely delegate the problem to them, as we do for Linux
> > where we delegate to distro vendors to build & distribute binaries.
> 
> Note that, to some extent, the same issues do apply to Win32 binaries
> (in particular, they are distributed under http and there are no
> signatures).  However, the situation is better in that they are hosted
> on an identifiable person's website, and of course Windows doesn't have
> something akin to Homebrew and Macports so there is no alternative to
> volunteers building and hosting the binaries.

It would be desirable & practical to address that for Win32, by building
the Win32 binaries at time of cutting the release, using the Mingw toolchain
via one of our formal Docker environments. Would need buy-in of our release
manager to accept the extra work for making releases though...

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 :|



reply via email to

[Prev in Thread] Current Thread [Next in Thread]