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

[Peter Xu <peterx@redhat.com>]

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