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

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

[Peter Xu]

Hi,

For example, I wanted to compile QEMU once and install it on multiple
systems.  What would be the suggested way to do so?

Is there something similar to "make bin-rpmpkg" for Linux?

Thanks in advance,

-- 
Peter Xu

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

[Fam Zheng]

On Tue, 06/12 14:24, Peter Xu wrote:
> Hi,
> 
> For example, I wanted to compile QEMU once and install it on multiple
> systems.  What would be the suggested way to do so?
> 
> Is there something similar to "make bin-rpmpkg" for Linux?
> 
> Thanks in advance,

No. The big question is the libraries. Even if you create the rpm, the libraries
that you have linked against are not necessarily available on the systems you
install. This means you either list all possible libraries as required in the
rpm spec, which is a waste, or the list is generated dynamically, which is not
trivial. For example, you can easily build QEMU against a custom glib, but it's
very tricky to generate an rpm from it that works on other systems.

For development, maybe it's easier to combine git and Ansible.

Fam

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

[Peter Xu]

On Tue, Jun 12, 2018 at 02:41:19PM +0800, Fam Zheng wrote:
> On Tue, 06/12 14:24, Peter Xu wrote:
> > Hi,
> > 
> > For example, I wanted to compile QEMU once and install it on multiple
> > systems.  What would be the suggested way to do so?
> > 
> > Is there something similar to "make bin-rpmpkg" for Linux?
> > 
> > Thanks in advance,
> 
> No. The big question is the libraries. Even if you create the rpm, the libraries
> that you have linked against are not necessarily available on the systems you
> install. This means you either list all possible libraries as required in the
> rpm spec, which is a waste, or the list is generated dynamically, which is not
> trivial. For example, you can easily build QEMU against a custom glib, but it's
> very tricky to generate an rpm from it that works on other systems.

That's true.  But my question was actually specific to when the
systems are sharing basically the same environment (kernel, library
versions, etc.).  A simple solution is that on each system I install
qemu official package then the dependencies will all be there, then I
install my custom package (which will possibly install the binaries
under /usr/local) and I run the customized binary.

> 
> For development, maybe it's easier to combine git and Ansible.

I would prefer avoid using git and compiling stuff, if there is a
way. :)

-- 
Peter Xu

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

[Fam Zheng]

On Tue, 06/12 14:52, Peter Xu wrote:
> On Tue, Jun 12, 2018 at 02:41:19PM +0800, Fam Zheng wrote:
> > On Tue, 06/12 14:24, Peter Xu wrote:
> > > Hi,
> > > 
> > > For example, I wanted to compile QEMU once and install it on multiple
> > > systems.  What would be the suggested way to do so?
> > > 
> > > Is there something similar to "make bin-rpmpkg" for Linux?
> > > 
> > > Thanks in advance,
> > 
> > No. The big question is the libraries. Even if you create the rpm, the libraries
> > that you have linked against are not necessarily available on the systems you
> > install. This means you either list all possible libraries as required in the
> > rpm spec, which is a waste, or the list is generated dynamically, which is not
> > trivial. For example, you can easily build QEMU against a custom glib, but it's
> > very tricky to generate an rpm from it that works on other systems.
> 
> That's true.  But my question was actually specific to when the
> systems are sharing basically the same environment (kernel, library
> versions, etc.).  A simple solution is that on each system I install
> qemu official package then the dependencies will all be there, then I
> install my custom package (which will possibly install the binaries
> under /usr/local) and I run the customized binary.

Then simply do

    ./configure --prefix=/tmp/qemu-install && \
    make && \
    make install && \
    scp -r /tmp/qemu-install $remote

?

Fam

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

[Peter Xu]

On Tue, Jun 12, 2018 at 03:01:52PM +0800, Fam Zheng wrote:
> On Tue, 06/12 14:52, Peter Xu wrote:
> > On Tue, Jun 12, 2018 at 02:41:19PM +0800, Fam Zheng wrote:
> > > On Tue, 06/12 14:24, Peter Xu wrote:
> > > > Hi,
> > > > 
> > > > For example, I wanted to compile QEMU once and install it on multiple
> > > > systems.  What would be the suggested way to do so?
> > > > 
> > > > Is there something similar to "make bin-rpmpkg" for Linux?
> > > > 
> > > > Thanks in advance,
> > > 
> > > No. The big question is the libraries. Even if you create the rpm, the libraries
> > > that you have linked against are not necessarily available on the systems you
> > > install. This means you either list all possible libraries as required in the
> > > rpm spec, which is a waste, or the list is generated dynamically, which is not
> > > trivial. For example, you can easily build QEMU against a custom glib, but it's
> > > very tricky to generate an rpm from it that works on other systems.
> > 
> > That's true.  But my question was actually specific to when the
> > systems are sharing basically the same environment (kernel, library
> > versions, etc.).  A simple solution is that on each system I install
> > qemu official package then the dependencies will all be there, then I
> > install my custom package (which will possibly install the binaries
> > under /usr/local) and I run the customized binary.
> 
> Then simply do
> 
>     ./configure --prefix=/tmp/qemu-install && \
>     make && \
>     make install && \
>     scp -r /tmp/qemu-install $remote
> 
> ?

Yeh, maybe. :)

But it'll still be good if we can have a single package to play around
with.  If there is no known way to do, we can try to figure a way out.

-- 
Peter Xu

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

[Liviu Ionescu]

On 12 June 2018 at 10:44:09, Peter Xu (peterx@redhat.com) wrote:

> But it'll still be good if we can have a single package to play around
> with. If there is no known way to do, we can try to figure a way out.

you can take a look at:

https://github.com/gnu-mcu-eclipse/qemu-build

the scripts can create the binary distributions for windows, linux and
macos in one run, with all required libraries and everything.

the result looks like this:

https://github.com/gnu-mcu-eclipse/qemu/releases


regards,

Liviu

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

[Peter Maydell]

On 12 June 2018 at 07:24, Peter Xu <peterx@redhat.com> wrote:
> For example, I wanted to compile QEMU once and install it on multiple
> systems.  What would be the suggested way to do so?

For this, I would recommend using whatever the packaging
format for those systems is. Eg for Debian use the existing
Debian QEMU packages, for Redhat systems use RPMs, etc.
If you want a newer version of QEMU than is in the distro's
packages, you can probably forward port the packaging parts
to a newer QEMU without too much pain.

Or you can use a distro-agnostic packaging tool of some sort;
there are a few out there but I have no particular recommendations.

thanks
-- PMM

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

[Laszlo Ersek]

Hi Fam,

On 06/12/18 08:41, Fam Zheng wrote:
> On Tue, 06/12 14:24, Peter Xu wrote:
>> Hi,
>>
>> For example, I wanted to compile QEMU once and install it on multiple
>> systems.  What would be the suggested way to do so?
>>
>> Is there something similar to "make bin-rpmpkg" for Linux?
>>
>> Thanks in advance,
> 
> No. The big question is the libraries. Even if you create the rpm, the libraries
> that you have linked against are not necessarily available on the systems you
> install. This means you either list all possible libraries as required in the
> rpm spec, which is a waste, or the list is generated dynamically, which is not
> trivial. For example, you can easily build QEMU against a custom glib, but it's
> very tricky to generate an rpm from it that works on other systems.
> 
> For development, maybe it's easier to combine git and Ansible.

libvirt supports RPM builds out of the upstream git tree:

  ./autogen.sh ...
  make rpm

However, while QEMU doesn't support that, Peter's idea can be solved
quite simply:

* run QEMU's configure with "--prefix=...". For example,
--prefix=/opt/qemu-<version>.

* If you make sure that the prefix configured above is writeable to a
non-root user, then "make install" can be executed without becoming root
first.

* You can then tar up the installed file tree under prefix, and extract
it on other hosts (at the same absolute prefix). If the installation is
no longer needed, you can simply remove the file tree under the prefix.

* The above procedure works basically for all open source packages
nowadays; however in order to actually use packages installed like this,
a number of environment variables may have to be extended so they refer
to various subdirectories under "prefix":

- CPLUS_INCLUDE_PATH
  (so g++ can find include files)
- C_INCLUDE_PATH
  (so gcc can find include files)
- INFOPATH
  (so "info" can find docs)
- LD_LIBRARY_PATH
  (so ld.so can load shared objects at executable startup)
- LIBRARY_PATH
  (so gcc/g++/ld can resolve "-l" options at link editing time)
- MANPATH
  (so "man" can find docs)
- PATH
  (so the shell finds the binary)
- PKG_CONFIG_PATH
  (modern replacement for CPLUS_INCLUDE_PATH, C_INCLUDE_PATH,
  and LIBRARY_PATH)
- PYTHONPATH
  (so python can find python modules)
- ...

On my laptop, I have a bunch of packages installed like this, and I have
a script that traverses /opt and generates another script that assigns
all of the above variables. This latter script is then sourced by my
~/.bashrc.

Considering QEMU specifically, only two of the above variables need to
be extended in practice:

- MANPATH: append <prefix>/share/man
- PATH: append <prefix>/bin

Summary: (1) configure QEMU with option "--prefix", (2) give rwx on
"prefix" to the user that builds and installs QEMU, (3) build and
install QEMU as that user, (3) transfer the tree under prefix to another
host, (4) expand to the same prefix on the target, (5) update MANPATH
and PATH on the target.

Thanks
Laszlo

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

[Laszlo Ersek]

On 06/12/18 09:01, Fam Zheng wrote:

>     scp -r /tmp/qemu-install $remote

"tar -c | ssh $remote tar -x" is generally much more performant than scp
(because of asynchronity), plus "tar" can transfer a bunch of extended
file attributes too, if parametrized correctly (my preference is "--acls
--selinux --xattrs" when it matters).

For progress updates, pass "-v" to the remote tar, or else insert "pv"
("pipe viewer") between the local tar and ssh.

Thanks,
Laszlo

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

[Peter Xu]

On Tue, Jun 12, 2018 at 01:29:32PM +0200, Laszlo Ersek wrote:
> Hi Fam,
> 
> On 06/12/18 08:41, Fam Zheng wrote:
> > On Tue, 06/12 14:24, Peter Xu wrote:
> >> Hi,
> >>
> >> For example, I wanted to compile QEMU once and install it on multiple
> >> systems.  What would be the suggested way to do so?
> >>
> >> Is there something similar to "make bin-rpmpkg" for Linux?
> >>
> >> Thanks in advance,
> > 
> > No. The big question is the libraries. Even if you create the rpm, the libraries
> > that you have linked against are not necessarily available on the systems you
> > install. This means you either list all possible libraries as required in the
> > rpm spec, which is a waste, or the list is generated dynamically, which is not
> > trivial. For example, you can easily build QEMU against a custom glib, but it's
> > very tricky to generate an rpm from it that works on other systems.
> > 
> > For development, maybe it's easier to combine git and Ansible.
> 
> libvirt supports RPM builds out of the upstream git tree:
> 
>   ./autogen.sh ...
>   make rpm
> 
> However, while QEMU doesn't support that, Peter's idea can be solved
> quite simply:
> 
> * run QEMU's configure with "--prefix=...". For example,
> --prefix=/opt/qemu-<version>.
> 
> * If you make sure that the prefix configured above is writeable to a
> non-root user, then "make install" can be executed without becoming root
> first.
> 
> * You can then tar up the installed file tree under prefix, and extract
> it on other hosts (at the same absolute prefix). If the installation is
> no longer needed, you can simply remove the file tree under the prefix.
> 
> * The above procedure works basically for all open source packages
> nowadays; however in order to actually use packages installed like this,
> a number of environment variables may have to be extended so they refer
> to various subdirectories under "prefix":
> 
> - CPLUS_INCLUDE_PATH
>   (so g++ can find include files)
> - C_INCLUDE_PATH
>   (so gcc can find include files)
> - INFOPATH
>   (so "info" can find docs)
> - LD_LIBRARY_PATH
>   (so ld.so can load shared objects at executable startup)
> - LIBRARY_PATH
>   (so gcc/g++/ld can resolve "-l" options at link editing time)
> - MANPATH
>   (so "man" can find docs)
> - PATH
>   (so the shell finds the binary)
> - PKG_CONFIG_PATH
>   (modern replacement for CPLUS_INCLUDE_PATH, C_INCLUDE_PATH,
>   and LIBRARY_PATH)
> - PYTHONPATH
>   (so python can find python modules)
> - ...
> 
> On my laptop, I have a bunch of packages installed like this, and I have
> a script that traverses /opt and generates another script that assigns
> all of the above variables. This latter script is then sourced by my
> ~/.bashrc.
> 
> Considering QEMU specifically, only two of the above variables need to
> be extended in practice:
> 
> - MANPATH: append <prefix>/share/man
> - PATH: append <prefix>/bin

These steps might be a bit heavy-weighted for debugging purpose of
mine, but please take my sincere thanks on all these steps!  I believe
I could use the idea somewhere, for example, this marco list is really
a good thing to know when debugging libraries with old versions.
Also, the "tar + pipe" magic you offered in the other thread with Fam
is nice and more light-weighted to me.

I'm considering maybe I'll read about how to "make binrpm" for QEMU
some day in case it'll ease some of us.

> 
> Summary: (1) configure QEMU with option "--prefix", (2) give rwx on
> "prefix" to the user that builds and installs QEMU, (3) build and
> install QEMU as that user, (3) transfer the tree under prefix to another
> host, (4) expand to the same prefix on the target, (5) update MANPATH
> and PATH on the target.

And... you even provided a summary for all the steps!

Thanks again, Laszlo!

-- 
Peter Xu

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

[Peter Xu]

On Tue, Jun 12, 2018 at 12:53:36AM -0700, Liviu Ionescu wrote:
> On 12 June 2018 at 10:44:09, Peter Xu (peterx@redhat.com) wrote:
> 
> > But it'll still be good if we can have a single package to play around
> > with. If there is no known way to do, we can try to figure a way out.
> 
> you can take a look at:
> 
> https://github.com/gnu-mcu-eclipse/qemu-build
> 
> the scripts can create the binary distributions for windows, linux and
> macos in one run, with all required libraries and everything.
> 
> the result looks like this:
> 
> https://github.com/gnu-mcu-eclipse/qemu/releases

This might be a bit heavy weighted to me (I would only use that for
debugging purpose basically on single platform, and more frequently),
but still good to know such a project and thank you for your reply!

-- 
Peter Xu

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

[Peter Xu]

On Tue, Jun 12, 2018 at 09:52:45AM +0100, Peter Maydell wrote:
> On 12 June 2018 at 07:24, Peter Xu <peterx@redhat.com> wrote:
> > For example, I wanted to compile QEMU once and install it on multiple
> > systems.  What would be the suggested way to do so?
> 
> For this, I would recommend using whatever the packaging
> format for those systems is. Eg for Debian use the existing
> Debian QEMU packages, for Redhat systems use RPMs, etc.
> If you want a newer version of QEMU than is in the distro's
> packages, you can probably forward port the packaging parts
> to a newer QEMU without too much pain.
> 
> Or you can use a distro-agnostic packaging tool of some sort;
> there are a few out there but I have no particular recommendations.

I'll start my investigation with RPM first.  Thanks Peter.

-- 
Peter Xu

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

[Daniel P. Berrangé]

On Wed, Jun 13, 2018 at 12:02:59PM +0800, Peter Xu wrote:
> On Tue, Jun 12, 2018 at 09:52:45AM +0100, Peter Maydell wrote:
> > On 12 June 2018 at 07:24, Peter Xu <peterx@redhat.com> wrote:
> > > For example, I wanted to compile QEMU once and install it on multiple
> > > systems.  What would be the suggested way to do so?
> > 
> > For this, I would recommend using whatever the packaging
> > format for those systems is. Eg for Debian use the existing
> > Debian QEMU packages, for Redhat systems use RPMs, etc.
> > If you want a newer version of QEMU than is in the distro's
> > packages, you can probably forward port the packaging parts
> > to a newer QEMU without too much pain.
> > 
> > Or you can use a distro-agnostic packaging tool of some sort;
> > there are a few out there but I have no particular recommendations.
> 
> I'll start my investigation with RPM first.  Thanks Peter.

If you're interested in Fedora, I maintain a Copr repository which
provides RPMs for every QEMU version since 1.4.0 and every libvirt
version since 1.2.0...

  https://copr.fedorainfracloud.org/coprs/berrange/virt-ark/

Yeah, Fedora 28 is missing, but I'll be adding it real soon.

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

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

[Peter Xu]

On Wed, Jun 13, 2018 at 10:28:09AM +0100, Daniel P. Berrangé wrote:
> On Wed, Jun 13, 2018 at 12:02:59PM +0800, Peter Xu wrote:
> > On Tue, Jun 12, 2018 at 09:52:45AM +0100, Peter Maydell wrote:
> > > On 12 June 2018 at 07:24, Peter Xu <peterx@redhat.com> wrote:
> > > > For example, I wanted to compile QEMU once and install it on multiple
> > > > systems.  What would be the suggested way to do so?
> > > 
> > > For this, I would recommend using whatever the packaging
> > > format for those systems is. Eg for Debian use the existing
> > > Debian QEMU packages, for Redhat systems use RPMs, etc.
> > > If you want a newer version of QEMU than is in the distro's
> > > packages, you can probably forward port the packaging parts
> > > to a newer QEMU without too much pain.
> > > 
> > > Or you can use a distro-agnostic packaging tool of some sort;
> > > there are a few out there but I have no particular recommendations.
> > 
> > I'll start my investigation with RPM first.  Thanks Peter.
> 
> If you're interested in Fedora, I maintain a Copr repository which
> provides RPMs for every QEMU version since 1.4.0 and every libvirt
> version since 1.2.0...
> 
>   https://copr.fedorainfracloud.org/coprs/berrange/virt-ark/
> 
> Yeah, Fedora 28 is missing, but I'll be adding it real soon.

Good to know this.

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?

Regards,

-- 
Peter Xu

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

[Daniel P. Berrangé]

On Thu, Jun 14, 2018 at 10:55:21AM +0800, Peter Xu wrote:
> On Wed, Jun 13, 2018 at 10:28:09AM +0100, Daniel P. Berrangé wrote:
> > On Wed, Jun 13, 2018 at 12:02:59PM +0800, Peter Xu wrote:
> > > On Tue, Jun 12, 2018 at 09:52:45AM +0100, Peter Maydell wrote:
> > > > On 12 June 2018 at 07:24, Peter Xu <peterx@redhat.com> wrote:
> > > > > For example, I wanted to compile QEMU once and install it on multiple
> > > > > systems.  What would be the suggested way to do so?
> > > > 
> > > > For this, I would recommend using whatever the packaging
> > > > format for those systems is. Eg for Debian use the existing
> > > > Debian QEMU packages, for Redhat systems use RPMs, etc.
> > > > If you want a newer version of QEMU than is in the distro's
> > > > packages, you can probably forward port the packaging parts
> > > > to a newer QEMU without too much pain.
> > > > 
> > > > Or you can use a distro-agnostic packaging tool of some sort;
> > > > there are a few out there but I have no particular recommendations.
> > > 
> > > I'll start my investigation with RPM first.  Thanks Peter.
> > 
> > If you're interested in Fedora, I maintain a Copr repository which
> > provides RPMs for every QEMU version since 1.4.0 and every libvirt
> > version since 1.2.0...
> > 
> >   https://copr.fedorainfracloud.org/coprs/berrange/virt-ark/
> > 
> > Yeah, Fedora 28 is missing, but I'll be adding it real soon.
> 
> Good to know this.
> 
> 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?

The QEMU spec I'm using for virt-ark is very much cut-down and simplified
and doesn't try to follow best practices for packaging [1]

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].

Regards,
Daniel

[1] https://pagure.io/virt-ark/blob/master/f/qemu-ark.spec.in
[2] https://libvirt.org/git/?p=libvirt.git;a=blob;f=libvirt.spec.in;hb=HEAD
[3] https://src.fedoraproject.org/rpms/qemu/blob/master/f/qemu.spec
-- 
|: 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 :|

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

[Peter Maydell]

On 14 June 2018 at 09:14, Daniel P. Berrangé <berrange@redhat.com> 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...

thanks
-- PMM

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

[Peter Xu]

On Thu, Jun 14, 2018 at 11:50:23AM +0100, Peter Maydell wrote:
> On 14 June 2018 at 09:14, Daniel P. Berrangé <berrange@redhat.com> 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

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

[Alex Bennée]

Peter Xu <peterx@redhat.com> writes:

> On Thu, Jun 14, 2018 at 11:50:23AM +0100, Peter Maydell wrote:
>> On 14 June 2018 at 09:14, Daniel P. Berrangé <berrange@redhat.com> 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

I suspect the kernel is a special case as there aren't that many
dependencies or interactions to worry about. That said I think the make
install logic interfaces with some distro supplied hooks.

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

I could see an argument for hosting distro-agnostic packaging in the
QEMU source tree for things like snap or flatpak. However there is no
one uniform packaging approach for either deb or rpm based systems. They
all have their own rules and approaches to where things go that means
they are best served by the respective distributions.

>
> Regards,


--
Alex Bennée