[fedora-virt] Spec weirdness

[Daniel P. Berrange]

On Mon, Aug 10, 2009 at 10:40:16AM -0700, Jesse Keating wrote:
> I'm looking at the spec file for libguestfs, and all I can say is WTF.
> There is a lot of crazyness going on in this spec, chroots within
> chroots, making a repo of yum cache packages and using it again, calling
> qemu, and none of it is really documented in the spec as for what and
> why things are done this way.
> 
> The review for this is extremely light on comments regarding the spec
> file construction as well, it looks very suspiciously like "it built and
> passed rpmlint, let it in!"

I didn't do the review myself, but looking at the specfile in devel/
it's a pretty clean & well written spec. That said I do agree it would
benefit from comment explaining why it needs to build a yum repository.
The spawning of QEMU is just what libguestfs as an application is all
about & you shouldn't need to document the application itself in the
spec file.

Anyway, here's an explanation of what libguestfs as a app does during
its build (nb this is not fedora specific - it does similar for all
distros, give or take a bit)

Part of the libguestfs application is a filesystem image that is run within
a virtual machine. Since distributing pre-built blobs is bad, libguestfs
prefers to build the filesystem from a distributions pristine package repos.
On Fedora this is done using  febootstrap, which is a Fedora equivalent
of debootstrap from Debian world & indeed it uses debootstrap on Debian. 
The idea of (fe|de)bootstrap is to allow ordinary unprivileged users to 
be able to install a set of packages (RPMS / Debs) into a virtual root 
directory of their own, without needing any privileged component. 
This is done by using fakeroot & fakechroot. If a user builds libguestfs 
straight from a upstream release, or GIT repo, then the libguestfs build 
system uses a yum config that points to an online Fedora yum repo. After
populating the root dir, it pulls it all together into a fs image that
is what libguestfs will later use at runtime.

Now back to the Koji bit. Since libguestfs has a build system which works
completely unprivileged technically there are no specific features required
in the Fedora buildsystem required in order to support it. The default
mode of operation though, builds from an online YUM repo - since that 
YUm repo may change at anytime its not desirable to use that from a RPM
formal build.  Thus, the RPM spec just configures libguestfs to use a 
local YUM repo, and populates this using the RPMs that mock has already
deployed into the RPM buildroot. This ensure the filesystem image thats
built uses a predictable set of RPM n-e-v-rs. ie, if you can recreate 
the original mock buildroot, you'll get the same libguestfs image coming
back out. 

The one area where I see it could be useful to have explicit mock or
koji suport, would be if they explicitly made the yum repo available,
so the spec didn't rely on the directory of RPMs that mock leaves 
visible. We certainly would not want to make the libguestfs build
process itself be tied into mock though - they should be loosely
coupled, since libguestfs needs to be easily buildable from non-Fedora
distros, as well as outside of mock/koji. 

So in summary, the only real special requirement here is that libguestfs
needs a reproducable / stable YUM repo to point at during build.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|