qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Is there a way to package QEMU binaries?


From: Peter Xu
Subject: Re: [Qemu-devel] Is there a way to package QEMU binaries?
Date: Thu, 14 Jun 2018 19:03:22 +0800
User-agent: Mutt/1.9.5 (2018-04-13)

On Thu, Jun 14, 2018 at 11:50:23AM +0100, Peter Maydell wrote:
> On 14 June 2018 at 09:14, Daniel P. Berrangé <address@hidden> wrote:
> > On Thu, Jun 14, 2018 at 10:55:21AM +0800, Peter Xu wrote:
> >> Then is there an easy way to port the specfile and tools to QEMU
> >> repository so that we can pack that even with a git tree?
> 
> > Well if we want to have a RPM spec file for QEMU distributed with upstream
> > QEMU, then I think it would be better todo what libvirt does[2], and simply
> > have the real Fedora  specfile kept in QEMU git [3].
> 
> I would prefer not to. I think packaging is a job for downstream
> distributors, and having our own (probably under-maintained)
> version of the packaging infrastructure in upstream git just
> makes things awkward for downstream, and requires us to make
> choices about which distros we think "important" enough to
> provide packaging for...

AFAIU that's not a problem; we can just provide more ways to package
the system gradually, just like what Linux did:

Kernel packaging:
  rpm-pkg             - Build both source and binary RPM kernel packages
  binrpm-pkg          - Build only the binary kernel RPM package
  deb-pkg             - Build both source and binary deb kernel packages
  bindeb-pkg          - Build only the binary kernel deb package
  snap-pkg            - Build only the binary kernel snap package (will connect 
to external hosts)
  tar-pkg             - Build the kernel as an uncompressed tarball
  targz-pkg           - Build the kernel as a gzip compressed tarball
  tarbz2-pkg          - Build the kernel as a bzip2 compressed tarball
  tarxz-pkg           - Build the kernel as a xz compressed tarball

But it seems that this package thing is not really that welcomed (and
after all we have multiple specfiles here and there).  Then I think
I'll just live with it now.

Regards,

-- 
Peter Xu



reply via email to

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