12:40 p.m.
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'd really like to see some comments around what's going on here, and
maybe some discussion on public lists of what you're trying to do and
whether or not there are better ways to do that within our buildsystem.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
1:17 p.m.
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 :|
1:36 p.m.
On Mon, Aug 10, 2009 at 07:17:38PM +0100, Daniel P. Berrange wrote:
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!"
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
BTW, for those not familiar with fakeroot/fakechroot, the man pages have
quite useful descriptions
For fakeroot
fakeroot runs a command in an environment wherein it appears to
have root privileges for file manipulation. This is useful for
allowing users to create archives (tar, ar, .deb etc.) with
files in them with root permissions/ownership. Without fakeroot
one would need to have root privileges to create the constituent
files of the archives with the correct permissions and owner-
ship, and then pack them up, or one would have to construct the
archives directly, without using the archiver.
fakeroot works by replacing the file manipulation library func-
tions (chmod(2), stat(2) etc.) by ones that simulate the effect
the real library functions would have had, had the user really
been root. These wrapper functions are in a shared library
/usr/lib/libfakeroot.so* which is loaded through the LD_PRELOAD
mechanism of the dynamic loader. (See ld.so(8))
And for fakechroot
fakechroot runs a command in an environment were is additional
possibility to use chroot(8) command without root privileges.
This is useful for allowing users to create own chrooted
environment with possibility to install another packages without
need for root privileges.
fakechroot replaces more library functions (chroot(2), open(2),
etc.) by ones that simulate the effect the real library
functions would have had, had the user really been in chroot.
These wrapper functions are in a shared library
/usr/lib/fakechroot/libfakechroot.so which is loaded through the
LD_PRELOAD mechanism of the dynamic loader. (See ld.so(8))
....
In the current version, the fakechroot does not provide the
fakeroot(1) functionality! You might to call fakechroot with
fakeroot command, if you want to emulate root environment, i.e.:
$ fakeroot fakechroot /usr/sbin/chroot /tmp/debian /bin/sh
# id
uid=0(root) gid=0(root) groups=0(root)
And most importantly of all on security
fakeroot is a regular, non-setuid program. It does not enhance a
userâs privileges, or decrease the systemâs security.
fakechroot is a regular, non-setuid program. It does not
enhance a userâs privileges, or decrease the systemâs security.
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 :|
1:50 p.m.
On Mon, Aug 10, 2009 at 07:17:38PM +0100, Daniel P. Berrange wrote:
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.
And indeed Debian are now packaging libguestfs. They ported it to use
debootstrap instead of febootstrap, but the build requirements are the
same:
http://pkg-libvirt.alioth.debian.org/packages/unstable/
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
1:45 p.m.
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.
Hey Jesse, I'll explain below what the general idea is, then provide
at the end some commentary inline on specific points within the
specfile. It certainly is a complex specfile.
In case you aren't familiar with it, libguestfs (http://libguestfs.org)
is a tool for modifying VM disk images. For example:
$ guestfish -a Fedora10.img
Welcome to guestfish, the libguestfs filesystem interactive shell for
editing virtual machine filesystems.
Type: 'help' for help with commands
'quit' to quit the shell
<fs> run
<fs> list-devices
/dev/vda
<fs> list-partitions
/dev/vda1
/dev/vda2
/dev/vda3
<fs> lvs
/dev/VolGroup00/LogVol00
/dev/VolGroup00/LogVol01
<fs> file /dev/VolGroup00/LogVol00
Linux rev 1.0 ext3
filesystem data (large files)
<fs> mount /dev/VolGroup00/LogVol00 /
<fs> cat /etc/redhat-release
Fedora release 10 (Cambridge)
<fs> vi /etc/passwd
<fs> ^D
What we do to make this happen is run a small Fedora distro (called
the "appliance") under qemu which is attached to the disk image in
question. The appliance runs a Linux kernel, LVM tools etc etc and
thus has full access to the disk. You can also run qemu as non-root,
which means you don't need to be root to edit disk images.
The complexity in the specfile is mainly around building this
appliance.
We use a tool called febootstrap which is basically a shell script
that runs 'yum' as non-root, using Debian's fakeroot and fakechroot
programs.
febootstrap can take any yum repository and turn it into an appliance,
without needing root permission:
$ febootstrap fedora-11 ./f11
$ febootstrap-to-initramfs ./f11 > initrd.img
Of course during the Koji build we don't have a yum repository, and we
don't have (or want) network access. So we make one using createrepo
+ the BuildRequired rpms from the mock cache.
There's a further complexity here -- a normal appliance would actually
contain the kernel + glibc + libraries + programs. However that is
undesirable from a Fedora point of view, since it's very similar to
static linking. If we really shipped that as an appliance then there
would be obvious security / patching headaches if (for example) glibc
had a security bug. Therefore we don't actually bundle any binaries.
We remove those from the final appliance, and get them from the host
system at runtime. The technique is called building a "supermin
appliance" and it's described here: http://libguestfs.org/README.txt
under "supermin appliance" It is important to reiterate that the
appliance we ship in the RPM *does not* contain any libraries or
binaries. We just remember where those files were, and pull them out
of the host's filesystem at runtime.
From the point of view of improving Koji (or mock) it would be nice to
have a more official method to access the build RPMs, although the
technique we are using works fine.
On to the specfile itself:
# Enable to build w/o network.
%global buildnonet 1
Summary: Access and modify virtual machine disk images
Name: libguestfs
[...]
# Basic build requirements:
BuildRequires: /usr/bin/pod2man
BuildRequires: /usr/bin/pod2text
BuildRequires: febootstrap >= 2.3
BuildRequires: augeas-devel >= 0.5.0
BuildRequires: readline-devel
BuildRequires: squashfs-tools
BuildRequires: qemu-kvm >= 0.10-7
BuildRequires: createrepo
BuildRequires: glibc-static
# This is only needed for RHEL 5 because readline-devel doesn't
# properly depend on it, but doesn't do any harm on other platforms:
BuildRequires: ncurses-devel
These are the basic build requires for making the actual package.
# Build requirements for the appliance (see 'make.sh.in' in the source):
BuildRequires: kernel, bash, coreutils, lvm2, ntfs-3g, util-linux-ng
BuildRequires: MAKEDEV, net-tools, augeas-libs, file
BuildRequires: module-init-tools, procps, strace, iputils
BuildRequires: dosfstools, zerofree, lsof, scrub
%ifarch %{ix86} x86_64
BuildRequires: grub, ntfsprogs
%endif
These are the BRs reflecting what is inside the appliance ...
# Must match the above set of BuildRequires exactly!
Requires: kernel, bash, coreutils, lvm2, ntfs-3g, util-linux-ng
Requires: MAKEDEV, net-tools, augeas-libs, file
Requires: module-init-tools, procps, strace, iputils
Requires: dosfstools, zerofree, lsof, scrub
%ifarch %{ix86} x86_64
Requires: grub, ntfsprogs
%endif
... and at runtime we need the same set of Requires, because of the
supermin appliance described above. Those files that we evicted from
the appliance at build time must exist in the host system at runtime.
[...]
%build
%if %{buildnonet}
mkdir repo
find /var/cache/yum -type f -name '*.rpm' -print0 | xargs -0 cp -t repo
createrepo repo
%define extra --with-mirror=file://$(pwd)/repo --with-repo=fedora-12
--with-updates=none
%else
%define extra %nil
%endif
This is the part where we create the local repository from the mock
cache. The %{buildnonet} switch allows people to build from the
Fedora repos instead if they do have network access.
# --with-net-if=ne2k_pci is a workaround for RHBZ#516022.
./configure \
--prefix=%{_prefix} --libdir=%{_libdir} \
--mandir=%{_mandir} \
--with-qemu="qemu-kvm qemu-system-%{_build_arch} qemu" \
--enable-debug-command \
--enable-supermin \
--with-net-if=ne2k_pci \
%{extra}
# This ensures that /usr/sbin/chroot is on the path. Not needed
# except for RHEL 5, it shouldn't do any harm on other platforms.
export PATH=/usr/sbin:$PATH
# 'INSTALLDIRS' ensures that perl libs are installed in the vendor dir
# not the site dir.
make INSTALLDIRS=vendor %{?_smp_mflags}
This bit is building the library + appliance + 6 language bindings.
%check
# Enable debugging - very useful if a test does fail, although
# it produces masses of output in the build.log.
export LIBGUESTFS_DEBUG=1
# Uncomment one of these, depending on whether you want to
# do a very long and thorough test ('make check') or just
# a quick test to see if things generally work.
# Tracking test issues:
# BZ archs branch reason
# 494075 ppc, ppc64 openbios bug causes "invalid/unsupported
opcode"
# 504273 ppc, ppc64 "no opcode defined"
# 505109 ppc, ppc64 "Boot failure! No secondary bootloader
specified"
# 502058 i386, x86-64 F-11 need to boot with noapic (WORKAROUND ENABLED)
# 502074 i386 F-11 commands segfault randomly
# 503236 i386 F-12 cryptomgr_test at doublefault_fn
# 507066 all F-12 sequence of chroot calls (FIXED)
# 513249 all F-12 guestfwd broken in qemu (FIXED)
# 516022 all F-12 virtio-net gives "Network is unreachable"
errors
# (WORKAROUND ENABLED)
# 516096 ? F-11 race condition in swapoff/blockdev --rereadpt
# 516543 ? F-12 qemu-kvm segfaults when run inside a VM
#%ifarch x86_64
#make check
#%endif
Normally we run the extensive test suite. However because of a bug in
qemu (#516543) we are unable to run that at the moment.
And the rest is just concerned with the language bindings.
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
6:56 p.m.
On Mon, 2009-08-10 at 19:45 +0100, Richard W.M. Jones wrote:
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.
Hey Jesse, I'll explain below what the general idea is, then provide
at the end some commentary inline on specific points within the
specfile. It certainly is a complex specfile.
In case you aren't familiar with it, libguestfs (http://libguestfs.org)
is a tool for modifying VM disk images. For example:
$ guestfish -a Fedora10.img
Welcome to guestfish, the libguestfs filesystem interactive shell for
editing virtual machine filesystems.
Type: 'help' for help with commands
'quit' to quit the shell
><fs> run
><fs> list-devices
/dev/vda
><fs> list-partitions
/dev/vda1
/dev/vda2
/dev/vda3
><fs> lvs
/dev/VolGroup00/LogVol00
/dev/VolGroup00/LogVol01
><fs> file /dev/VolGroup00/LogVol00
Linux rev 1.0 ext3 filesystem data (large files)
><fs> mount /dev/VolGroup00/LogVol00 /
><fs> cat /etc/redhat-release
Fedora release 10 (Cambridge)
><fs> vi /etc/passwd
><fs> ^D
What we do to make this happen is run a small Fedora distro (called
the "appliance") under qemu which is attached to the disk image in
question. The appliance runs a Linux kernel, LVM tools etc etc and
thus has full access to the disk. You can also run qemu as non-root,
which means you don't need to be root to edit disk images.
The complexity in the specfile is mainly around building this
appliance.
We use a tool called febootstrap which is basically a shell script
that runs 'yum' as non-root, using Debian's fakeroot and fakechroot
programs.
febootstrap can take any yum repository and turn it into an appliance,
without needing root permission:
$ febootstrap fedora-11 ./f11
$ febootstrap-to-initramfs ./f11 > initrd.img
Of course during the Koji build we don't have a yum repository, and we
don't have (or want) network access. So we make one using createrepo
+ the BuildRequired rpms from the mock cache.
There's a further complexity here -- a normal appliance would actually
contain the kernel + glibc + libraries + programs. However that is
undesirable from a Fedora point of view, since it's very similar to
static linking. If we really shipped that as an appliance then there
would be obvious security / patching headaches if (for example) glibc
had a security bug. Therefore we don't actually bundle any binaries.
We remove those from the final appliance, and get them from the host
system at runtime. The technique is called building a "supermin
appliance" and it's described here: http://libguestfs.org/README.txt
under "supermin appliance" It is important to reiterate that the
appliance we ship in the RPM *does not* contain any libraries or
binaries. We just remember where those files were, and pull them out
of the host's filesystem at runtime.
From the point of view of improving Koji (or mock) it would be nice to
have a more official method to access the build RPMs, although the
technique we are using works fine.
So first question, why isn't the chroot that mock created for you good
enough? Why do you have to create a second chroot?
On to the specfile itself:
# Enable to build w/o network.
%global buildnonet 1
Summary: Access and modify virtual machine disk images
Name: libguestfs
[...]
# Basic build requirements:
BuildRequires: /usr/bin/pod2man
BuildRequires: /usr/bin/pod2text
BuildRequires: febootstrap >= 2.3
BuildRequires: augeas-devel >= 0.5.0
BuildRequires: readline-devel
BuildRequires: squashfs-tools
BuildRequires: qemu-kvm >= 0.10-7
BuildRequires: createrepo
BuildRequires: glibc-static
# This is only needed for RHEL 5 because readline-devel doesn't
# properly depend on it, but doesn't do any harm on other platforms:
BuildRequires: ncurses-devel
These are the basic build requires for making the actual package.
# Build requirements for the appliance (see 'make.sh.in' in the source):
BuildRequires: kernel, bash, coreutils, lvm2, ntfs-3g, util-linux-ng
BuildRequires: MAKEDEV, net-tools, augeas-libs, file
BuildRequires: module-init-tools, procps, strace, iputils
BuildRequires: dosfstools, zerofree, lsof, scrub
%ifarch %{ix86} x86_64
BuildRequires: grub, ntfsprogs
%endif
These are the BRs reflecting what is inside the appliance ...
# Must match the above set of BuildRequires exactly!
Requires: kernel, bash, coreutils, lvm2, ntfs-3g, util-linux-ng
Requires: MAKEDEV, net-tools, augeas-libs, file
Requires: module-init-tools, procps, strace, iputils
Requires: dosfstools, zerofree, lsof, scrub
%ifarch %{ix86} x86_64
Requires: grub, ntfsprogs
%endif
... and at runtime we need the same set of Requires, because of the
supermin appliance described above. Those files that we evicted from
the appliance at build time must exist in the host system at runtime.
[...]
%build
%if %{buildnonet}
mkdir repo
find /var/cache/yum -type f -name '*.rpm' -print0 | xargs -0 cp -t repo
createrepo repo
%define extra --with-mirror=file://$(pwd)/repo --with-repo=fedora-12
--with-updates=none
%else
%define extra %nil
%endif
This is the part where we create the local repository from the mock
cache. The %{buildnonet} switch allows people to build from the
Fedora repos instead if they do have network access.
# --with-net-if=ne2k_pci is a workaround for RHBZ#516022.
./configure \
--prefix=%{_prefix} --libdir=%{_libdir} \
--mandir=%{_mandir} \
--with-qemu="qemu-kvm qemu-system-%{_build_arch} qemu" \
--enable-debug-command \
--enable-supermin \
--with-net-if=ne2k_pci \
%{extra}
# This ensures that /usr/sbin/chroot is on the path. Not needed
# except for RHEL 5, it shouldn't do any harm on other platforms.
export PATH=/usr/sbin:$PATH
# 'INSTALLDIRS' ensures that perl libs are installed in the vendor dir
# not the site dir.
make INSTALLDIRS=vendor %{?_smp_mflags}
This bit is building the library + appliance + 6 language bindings.
%check
# Enable debugging - very useful if a test does fail, although
# it produces masses of output in the build.log.
export LIBGUESTFS_DEBUG=1
# Uncomment one of these, depending on whether you want to
# do a very long and thorough test ('make check') or just
# a quick test to see if things generally work.
# Tracking test issues:
# BZ archs branch reason
# 494075 ppc, ppc64 openbios bug causes "invalid/unsupported
opcode"
# 504273 ppc, ppc64 "no opcode defined"
# 505109 ppc, ppc64 "Boot failure! No secondary bootloader
specified"
# 502058 i386, x86-64 F-11 need to boot with noapic (WORKAROUND ENABLED)
# 502074 i386 F-11 commands segfault randomly
# 503236 i386 F-12 cryptomgr_test at doublefault_fn
# 507066 all F-12 sequence of chroot calls (FIXED)
# 513249 all F-12 guestfwd broken in qemu (FIXED)
# 516022 all F-12 virtio-net gives "Network is unreachable"
errors
# (WORKAROUND ENABLED)
# 516096 ? F-11 race condition in swapoff/blockdev --rereadpt
# 516543 ? F-12 qemu-kvm segfaults when run inside a VM
#%ifarch x86_64
#make check
#%endif
Normally we run the extensive test suite. However because of a bug in
qemu (#516543) we are unable to run that at the moment.
And the rest is just concerned with the language bindings.
Rich.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
3:01 a.m.
On Wed, Aug 12, 2009 at 04:56:15PM -0700, Jesse Keating wrote:
So first question, why isn't the chroot that mock created for you
good
enough? Why do you have to create a second chroot?
We have to put custom files (configuration, /init etc.) into our
chroot, because the appliance we build is different from the host
under which it runs. We also rm -rf large parts of the appliance in
order to make it small enough to boot in memory.
Also we don't just build in mock. In fact that is the rare case.
Most people build using ./configure && make. And of course we support
Debian etc.
You can see how we build the appliance here:
http://git.et.redhat.com/?p=libguestfs.git;a=blob;f=appliance/make.sh.in;...
http://git.et.redhat.com/?p=libguestfs.git;a=blob;f=appliance/update.sh.i...
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://et.redhat.com/~rjones/libguestfs/
See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html
3:18 a.m.
On Thu, Aug 13, 2009 at 09:01:51AM +0100, Richard W.M. Jones wrote:
On Wed, Aug 12, 2009 at 04:56:15PM -0700, Jesse Keating wrote:
> So first question, why isn't the chroot that mock created for you good
> enough? Why do you have to create a second chroot?
We have to put custom files (configuration, /init etc.) into our
chroot, because the appliance we build is different from the host
under which it runs. We also rm -rf large parts of the appliance in
order to make it small enough to boot in memory.
Also we don't just build in mock. In fact that is the rare case.
Most people build using ./configure && make. And of course we support
Debian etc.
And also there are different requirements for package build and for
appliance for libguestfs. For example mock needs gcc, ... libguestfs don't.
If there will be mock cache available in mock's chroot, then may be Rich can
use them to prefill febootstrap cache.
SAL
3:36 a.m.
On Thu, Aug 13, 2009 at 10:18:39AM +0200, J?n ONDREJ (SAL) wrote:
On Thu, Aug 13, 2009 at 09:01:51AM +0100, Richard W.M. Jones wrote:
> On Wed, Aug 12, 2009 at 04:56:15PM -0700, Jesse Keating wrote:
> > So first question, why isn't the chroot that mock created for you good
> > enough? Why do you have to create a second chroot?
>
> We have to put custom files (configuration, /init etc.) into our
> chroot, because the appliance we build is different from the host
> under which it runs. We also rm -rf large parts of the appliance in
> order to make it small enough to boot in memory.
>
> Also we don't just build in mock. In fact that is the rare case.
> Most people build using ./configure && make. And of course we support
> Debian etc.
And also there are different requirements for package build and for
appliance for libguestfs. For example mock needs gcc, ... libguestfs don't.
If there will be mock cache available in mock's chroot, then may be Rich can
use them to prefill febootstrap cache.
That's what the specfile is already doing. It is pointing febootstrap
at a yum repo populated from the mock RPM cache inside the chroot.
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 :|
5376
days inactive
5379
days old
8 comments
4 participants
participants (4)
-
Daniel P. Berrange -
Jesse Keating -
Ján ONDREJ (SAL) -
Richard W.M. Jones