libguestfs under Debian / Ubuntu

[Tim Tassonis]

Hi all

Just came across libguestfs and, as a qemu user, this project really 
sound fantastic to me.

However, when I tried to compile the latest tarball, I failed,  mainly 
because of the inavalability of febootstrap, which obviously does not 
exist under ubuntu, and cannot be installed due to the lack of yum under 
ubuntu at least.

Is debian support planned, or is libguestfs designed to be a fedora-only 
project?

Bye
Tim

[Emre Erenoglu]

On Thu, Jun 11, 2009 at 6:09 PM, Tim Tassonis<timtas(a)cubic.ch> wrote:
>  However, when I tried to compile the latest tarball, I failed,  mainly
>  because of the inavalability of febootstrap, which obviously does not exist
>  under ubuntu, and cannot be installed due to the lack of yum under ubuntu at
>  least.
>
>  Is debian support planned, or is libguestfs designed to be a fedora-only
>  project? 
I also want to package libguestfs for our distro, Pardus, but unable
to do so due to this dependency.

-- 
Emre

[Richard W.M. Jones]

On Thu, Jun 11, 2009 at 08:46:19PM +0200, Emre Erenoglu wrote:
>  On Thu, Jun 11, 2009 at 6:09 PM, Tim Tassonis<timtas(a)cubic.ch>
> wrote:
>  >
>  > However, when I tried to compile the latest tarball, I failed,  mainly
>  > because of the inavalability of febootstrap, which obviously does not exist
>  > under ubuntu, and cannot be installed due to the lack of yum under ubuntu at
>  > least.
>  >
>  > Is debian support planned, or is libguestfs designed to be a fedora-only
>  > project?
>  
>  I also want to package libguestfs for our distro, Pardus, but unable
>  to do so due to this dependency. 
You can just compile yum on pretty much any distro.  The only major
dependencies are Python and rpm (which just needs a C compiler).
Debian ship a yum package and have been doing so for quite a long
time.

febootstrap is little more than a shell script which wraps around yum.

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/

[Daniel P. Berrange]

On Thu, Jun 11, 2009 at 06:09:50PM +0200, Tim Tassonis wrote:
>  Hi all
>  
>  Just came across libguestfs and, as a qemu user, this project really 
>  sound fantastic to me.
>  
>  However, when I tried to compile the latest tarball, I failed,  mainly 
>  because of the inavalability of febootstrap, which obviously does not 
>  exist under ubuntu, and cannot be installed due to the lack of yum under 
>  ubuntu at least. 
Even though Debian/Ubunut use APT for their package mgmt system, there
should not be any problem installing the YUM + RPM libraries. This 
should allow febootstrap to be built & run, and not impact your host 
OS package mgmt

>  Is debian support planned, or is libguestfs designed to be a
> fedora-only 
>  project? 
It is certainly intended to be able to build libguestfs on any Linux
host with new enough fakeroot/fakechroot + YUM/RPM libraries. IMHO
it doesn't make sense to try and use different OS for its internal 
appliance image, since that's not really a distro you need to interface
with at all as a user of libguestfs.

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

[Tim Tassonis]

Daniel P. Berrange wrote:
>  On Thu, Jun 11, 2009 at 06:09:50PM +0200, Tim Tassonis wrote:
> > Hi all
> >
> > Just came across libguestfs and, as a qemu user, this project really 
> > sound fantastic to me.
> >
> > However, when I tried to compile the latest tarball, I failed,  mainly 
> > because of the inavalability of febootstrap, which obviously does not 
> > exist under ubuntu, and cannot be installed due to the lack of yum under 
> > ubuntu at least.
>  
>  Even though Debian/Ubunut use APT for their package mgmt system, there
>  should not be any problem installing the YUM + RPM libraries. This 
>  should allow febootstrap to be built & run, and not impact your host 
>  OS package mgmt 
Yes, of course....but since it is mentioned that febootstrap is based on 
debootstrap, is there a technical reason for not just supporting 
debootstrap alternatively. I haven't got enough background regarding 
debootstrap/febootstrap and libguestfs to make a judgement about this 
though.

But to require any distribution to install yum/rpm just for this library 
  seems a bit intrusive to me. Requiring a specific distro packaging 
system for a package seems a bit distribution dependant to me.

Regards
Tim

[Emre Erenoglu]

On Thu, Jun 11, 2009 at 9:11 PM, Tim Tassonis<timtas(a)cubic.ch> wrote:
>  Daniel P. Berrange wrote:
> >
> > On Thu, Jun 11, 2009 at 06:09:50PM +0200, Tim Tassonis wrote:
> >>
> >> Hi all
> >>
> >> Just came across libguestfs and, as a qemu user, this project really
> >> sound fantastic to me.
> >>
> >> However, when I tried to compile the latest tarball, I failed,  mainly
> >> because of the inavalability of febootstrap, which obviously does not exist
> >> under ubuntu, and cannot be installed due to the lack of yum under ubuntu at
> >> least.
> >
> > Even though Debian/Ubunut use APT for their package mgmt system, there
> > should not be any problem installing the YUM + RPM libraries. This should
> > allow febootstrap to be built & run, and not impact your host OS package
> > mgmt
>
>  Yes, of course....but since it is mentioned that febootstrap is based on
>  debootstrap, is there a technical reason for not just supporting debootstrap
>  alternatively. I haven't got enough background regarding
>  debootstrap/febootstrap and libguestfs to make a judgement about this
>  though.
>
>  But to require any distribution to install yum/rpm just for this library
>   seems a bit intrusive to me. Requiring a specific distro packaging system
>  for a package seems a bit distribution dependant to me. 
This is exactly my problem. I didn't really analyze why febootstrap or
debootstrap might be technically needed, but I appreciate if there's
an alternative way to this requirement. Our distro, possibly some
others out there, do not have any {fe,de]bootstrap packages.

Thanks,

Emre

[Daniel P. Berrange]

On Thu, Jun 11, 2009 at 09:11:51PM +0200, Tim Tassonis wrote:
>  Daniel P. Berrange wrote:
>  >On Thu, Jun 11, 2009 at 06:09:50PM +0200, Tim Tassonis wrote:
>  >>Hi all
>  >>
>  >>Just came across libguestfs and, as a qemu user, this project really 
>  >>sound fantastic to me.
>  >>
>  >>However, when I tried to compile the latest tarball, I failed,  mainly 
>  >>because of the inavalability of febootstrap, which obviously does not 
>  >>exist under ubuntu, and cannot be installed due to the lack of yum under 
>  >>ubuntu at least.
>  >
>  >Even though Debian/Ubunut use APT for their package mgmt system, there
>  >should not be any problem installing the YUM + RPM libraries. This 
>  >should allow febootstrap to be built & run, and not impact your host 
>  >OS package mgmt
>  
>  Yes, of course....but since it is mentioned that febootstrap is based on 
>  debootstrap, is there a technical reason for not just supporting 
>  debootstrap alternatively. I haven't got enough background regarding 
>  debootstrap/febootstrap and libguestfs to make a judgement about this 
>  though. 
They are conceptually the same, but different implementations. debootstrap
takes a APT repository and uses a chroot to setup a distro install based 
off the Debian packages in that repo. febootstrap takes a YUM repository 
and uses a chroot to setup a distro install based off the RPM packages in
that repo. libguestfs uses a febootstrap to install a custom Fedora 11
appliance which it boots within QEMU in order to access the filesystems.
You can't use debootstrap to build a Fedora 11 appliance, and vica-verca.
So if you wanted to use debootstrap you'd have to come up with a recipe
that provided the same functionality as the febootstrap recipe. That's
doable, but more work than just installing RPM/YUM libraries IMHO.

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

[Emre Erenoglu]

On Thu, Jun 11, 2009 at 10:24 PM, Daniel P. Berrange<berrange(a)redhat.com> wrote:
>  that repo. libguestfs uses a febootstrap to install a custom Fedora 11
>  appliance which it boots within QEMU in order to access the filesystems. 
If the sole purpose of febootstrap is to install a custom F11
appliance to boot in qemu, why don't we prepare this image beforehand,
put it somewhere on the web, so that libguestfs can just use it
without needing to build this appliance again in each machine with
febootstrap or debootstrap?

I read the documentation of libguestfs, but still didn't understand
very well why we need to boot an OS within qemu for accessing guest
file systems. Can't we just use loop devices, kpartx and lvm tools?

Am i missing something here?

Thanks a lot,

-- 
Emre

[Richard W.M. Jones]

On Fri, Jun 12, 2009 at 01:14:07AM +0200, Emre Erenoglu wrote:
>  On Thu, Jun 11, 2009 at 10:24 PM, Daniel P.
> Berrange<berrange(a)redhat.com> wrote:
>  >
>  > that repo. libguestfs uses a febootstrap to install a custom Fedora 11
>  > appliance which it boots within QEMU in order to access the filesystems.
>  
>  If the sole purpose of febootstrap is to install a custom F11
>  appliance to boot in qemu, why don't we prepare this image beforehand,
>  put it somewhere on the web, so that libguestfs can just use it
>  without needing to build this appliance again in each machine with
>  febootstrap or debootstrap? 
We want you to be able to build everything from source.  Also it
allows you to customize the appliance by editing the script that
builds it (eg. leaving out a feature or adding other kernel modules).

In any case, febootstrap can build the appliance in under 3 minutes on
my machine, so this is hardly a problem for libguestfs.

>  I read the documentation of libguestfs, but still didn't
> understand
>  very well why we need to boot an OS within qemu for accessing guest
>  file systems. Can't we just use loop devices, kpartx and lvm tools? 
Because this would require root, and the point of libguestfs is that
nothing needs to be root.  'libguestfs.so' is a plain library - you
could link it to your webserver running as nobody.nobody, and it still
works.  Using loop devices has other disadvantages: it's liable to
leave temporary mounts & devices around if something fails, and it
doesn't work at all if there are conflicting VG names.

Rich.
 
-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw

[Emre Erenoglu]

On Fri, Jun 12, 2009 at 10:34 AM, Richard W.M. Jones <rjones(a)redhat.com&gt;wrote:

>  On Fri, Jun 12, 2009 at 01:14:07AM +0200, Emre Erenoglu wrote:
>  > On Thu, Jun 11, 2009 at 10:24 PM, Daniel P. Berrange&lt;berrange(a)redhat.com&gt;
>  wrote:
>  > >
>  > > that repo. libguestfs uses a febootstrap to install a custom Fedora 11
>  > > appliance which it boots within QEMU in order to access the
>  filesystems.
>  >
>  > If the sole purpose of febootstrap is to install a custom F11
>  > appliance to boot in qemu, why don't we prepare this image beforehand,
>  > put it somewhere on the web, so that libguestfs can just use it
>  > without needing to build this appliance again in each machine with
>  > febootstrap or debootstrap?
>
>  We want you to be able to build everything from source.  Also it
>  allows you to customize the appliance by editing the script that
>  builds it (eg. leaving out a feature or adding other kernel modules). 

>  In any case, febootstrap can build the appliance in under 3 minutes
> on
>  my machine, so this is hardly a problem for libguestfs. 

OK I see now. I would wish that if the configure script is not able to find
febootstrap, it would fall back into using a pre-cooked generic swiss army
knife image file instead. That would make libguestfs pretty trivial to
package for our distro or others, without needing to package yum and
febootstrap etc.

>  I read the documentation of libguestfs, but still didn't
> understand
>  > very well why we need to boot an OS within qemu for accessing guest
>  > file systems. Can't we just use loop devices, kpartx and lvm tools?
>
>
>  Because this would require root, and the point of libguestfs is that
>  nothing needs to be root.  'libguestfs.so' is a plain library - you
>  could link it to your webserver running as nobody.nobody, and it still
>  works.  Using loop devices has other disadvantages: it's liable to
>  leave temporary mounts & devices around if something fails, and it
>  doesn't work at all if there are conflicting VG names. 

OK, thanks a lot for this insight. I would say "why not use policykit when
privilege is needed, or mount images with fuse etc. ", but the possibility
to link to a webserver may not work this way :)  Anyway, I'm sure you
considered all these options previously, sorry for taking your time to ask
these again :)   You know, my only problem is with febootstrap and I'm
trying to find a way out of this dependency.

Thanks again,

-- 
Emre

[Richard W.M. Jones]

On Fri, Jun 12, 2009 at 10:51:09AM +0200, Emre Erenoglu wrote:
>  OK I see now. I would wish that if the configure script is not able
> to find
>  febootstrap, it would fall back into using a pre-cooked generic swiss army
>  knife image file instead. That would make libguestfs pretty trivial to
>  package for our distro or others, without needing to package yum and
>  febootstrap etc. 
In one sense we do offer that.  You can go to Koji[1], download the
latest build from here:

  http://koji.fedoraproject.org/koji/packageinfo?packageID=8391

and extract the appliance directly from those RPMs.  (This can even be
automated because Koji has an XML-RPC interface).

  rpm2cpio libguestfs-<version>.rpm | cpio -id

The appliance is the two files found in usr/lib{,64}/guestfs/*

However most Linux distros have strict rules about building from
source, so this isn't an appropriate method for them.

Rich.

[1] http://koji.fedoraproject.org/koji/

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

[Richard W.M. Jones]

On Fri, Jun 12, 2009 at 11:18:38AM +0100, Richard W.M. Jones wrote:
>  (This can even be
>  automated because Koji has an XML-RPC interface). 
BTW here's some OCaml code for extracting RPMs from Koji using
the XML-RPC interface.  Ought to give you a start:

http://hg.et.redhat.com/cgi-bin/hg-virt.cgi/applications/virt-mem--devel/...

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/

[Daniel P. Berrange]

On Fri, Jun 12, 2009 at 01:14:07AM +0200, Emre Erenoglu wrote:
>  On Thu, Jun 11, 2009 at 10:24 PM, Daniel P.
> Berrange<berrange(a)redhat.com> wrote:
>  >
>  > that repo. libguestfs uses a febootstrap to install a custom Fedora 11
>  > appliance which it boots within QEMU in order to access the filesystems.
>  
>  If the sole purpose of febootstrap is to install a custom F11
>  appliance to boot in qemu, why don't we prepare this image beforehand,
>  put it somewhere on the web, so that libguestfs can just use it
>  without needing to build this appliance again in each machine with
>  febootstrap or debootstrap? 
Providing pre-built binary OS images gets you into potentially complicated
license compliance issues. You as distributor of the binary have to comply
with the license of every single piece of software that went into the
binary. For the Fedora Project distributing a binary image of a Fedora
distro, compliance is easy because Fedora already ships all source RPMs.
If a non-Fedora entity wants to ships binaries of Fedora it needs to make
sure it can provide the corresponding source. It is not clearcut that it
can rely on Fedora to always ship the sources for it.  The safe option is
to always build from source and distribute everything you used to build
yourself. This is actually an argument *for* Debian using debootstrap
against a Debian repo, rather Debian using feboiotstrap+YUM + Fedora repos.

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

[Emre Erenoglu]

On Fri, Jun 12, 2009 at 12:29 PM, Daniel P. Berrange <berrange(a)redhat.com&gt;wrote:

>  On Fri, Jun 12, 2009 at 01:14:07AM +0200, Emre Erenoglu wrote:
>  > On Thu, Jun 11, 2009 at 10:24 PM, Daniel P. Berrange&lt;berrange(a)redhat.com&gt;
>  wrote:
>  > >
>  > > that repo. libguestfs uses a febootstrap to install a custom Fedora 11
>  > > appliance which it boots within QEMU in order to access the
>  filesystems.
>  >
>  > If the sole purpose of febootstrap is to install a custom F11
>  > appliance to boot in qemu, why don't we prepare this image beforehand,
>  > put it somewhere on the web, so that libguestfs can just use it
>  > without needing to build this appliance again in each machine with
>  > febootstrap or debootstrap?
>
>  Providing pre-built binary OS images gets you into potentially complicated
>  license compliance issues. You as distributor of the binary have to comply
>  with the license of every single piece of software that went into the
>  binary. For the Fedora Project distributing a binary image of a Fedora
>  distro, compliance is easy because Fedora already ships all source RPMs.
>  If a non-Fedora entity wants to ships binaries of Fedora it needs to make
>  sure it can provide the corresponding source. It is not clearcut that it
>  can rely on Fedora to always ship the sources for it.  The safe option is
>  to always build from source and distribute everything you used to build
>  yourself. This is actually an argument *for* Debian using debootstrap
>  against a Debian repo, rather Debian using feboiotstrap+YUM + Fedora repos.
>  
I see the situation. This binary distro download may also create a licensing
problem for our Pardus distro. I guess this leaves the following options:
1- package yum and febootstrap for Pardus and use them
2- create a "pabootstrap" package compatible with febootstrap and build a
Pardus appliance instead of fedora appliance
3- create a pre-cooked "compatible" pardus appliance image and use this one

For the last option, does it make any difference which distro is inside the
appliance? Is there anything specific to Fedora? say, if we support all
possible file system drivers as well as raid/lvm, would it still be needed
to have Fedora inside? Is there a requirements documents for this appliance?

Thanks a lot again for your patience for my never-ending questions, I really
appreciate and learn a lot from you guys.

Br,
Emre

[Daniel P. Berrange]

On Fri, Jun 12, 2009 at 12:37:11PM +0200, Emre Erenoglu wrote:
>  On Fri, Jun 12, 2009 at 12:29 PM, Daniel P. Berrange
> <berrange(a)redhat.com&gt;wrote:
>  
>  >
>  > Providing pre-built binary OS images gets you into potentially complicated
>  > license compliance issues. You as distributor of the binary have to comply
>  > with the license of every single piece of software that went into the
>  > binary. For the Fedora Project distributing a binary image of a Fedora
>  > distro, compliance is easy because Fedora already ships all source RPMs.
>  > If a non-Fedora entity wants to ships binaries of Fedora it needs to make
>  > sure it can provide the corresponding source. It is not clearcut that it
>  > can rely on Fedora to always ship the sources for it.  The safe option is
>  > to always build from source and distribute everything you used to build
>  > yourself. This is actually an argument *for* Debian using debootstrap
>  > against a Debian repo, rather Debian using feboiotstrap+YUM + Fedora repos.
>  >
>  
>  I see the situation. This binary distro download may also create a licensing
>  problem for our Pardus distro. I guess this leaves the following options:
>  1- package yum and febootstrap for Pardus and use them
>  2- create a "pabootstrap" package compatible with febootstrap and build a
>  Pardus appliance instead of fedora appliance
>  3- create a pre-cooked "compatible" pardus appliance image and use this one
>  
>  For the last option, does it make any difference which distro is inside the
>  appliance? Is there anything specific to Fedora? say, if we support all
>  possible file system drivers as well as raid/lvm, would it still be needed
>  to have Fedora inside? Is there a requirements documents for this appliance? 
Check out Richard's architecture diagram

http://libguestfs.org/guestfs.3.html#state_machine_and_low_level_event_api

AFAIK, the only critical thing for the appliance is that it runs the 
custom guestfsd daemon talking to over QMEMU's vmchannel device. If
you get that setup correctly then the choice of distro really shouldn't
make any real difference. It is mostly just a tools problem to build
yourself a image with the right pieces present.

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

[Richard W.M. Jones]

On Fri, Jun 12, 2009 at 12:37:11PM +0200, Emre Erenoglu wrote:
>  I see the situation. This binary distro download may also create a
> licensing
>  problem for our Pardus distro. I guess this leaves the following options:
>  1- package yum and febootstrap for Pardus and use them
>  2- create a "pabootstrap" package compatible with febootstrap and build a
>  Pardus appliance instead of fedora appliance 
Is Pardus rpm based, or in general what packaging format does it use?

>  3- create a pre-cooked "compatible" pardus appliance image
> and use this one
>  
>  For the last option, does it make any difference which distro is inside the
>  appliance? Is there anything specific to Fedora? say, if we support all
>  possible file system drivers as well as raid/lvm, would it still be needed
>  to have Fedora inside? Is there a requirements documents for this appliance? 
Dan is right - it doesn't make any difference what distro is used
inside the appliance.  The only requirement is that guestfsd is
running inside the appliance, and that guestfsd has access to all the
other programs it uses.  Common ones like sfdisk, lvm, mount, etc and
some not-so-common ones too - you can find a big list in the source
code, in 'appliance/make-initramfs.sh.in'.

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

[Richard W.M. Jones]

On Fri, Jun 12, 2009 at 12:20:14PM +0100, Richard W.M. Jones wrote:
>  code, in 'appliance/make-initramfs.sh.in'. 
Here:

http://git.et.redhat.com/?p=libguestfs.git;a=blob;f=appliance/make-initra...

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 75 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora

[Richard W.M. Jones]

On Fri, Jun 12, 2009 at 12:21:38PM +0100, Richard W.M. Jones wrote:
>  On Fri, Jun 12, 2009 at 12:20:14PM +0100, Richard W.M. Jones wrote:
>  > code, in 'appliance/make-initramfs.sh.in'.
>  
>  Here:
>  
>
> http://git.et.redhat.com/?p=libguestfs.git;a=blob;f=appliance/make-initra...
Just so you know, in the latest changeset I've renamed this file from
the rather obscure 'make-initramfs.sh.in' to just
'appliance/make.sh.in':

http://git.et.redhat.com/?p=libguestfs.git;a=commit;h=2e25c4255746b144932...

RIch.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw

[Charles Duffy]

On Fri, Jun 12, 2009 at 5:37 AM, Emre Erenoglu <erenoglu(a)gmail.com&gt; wrote:

>  I see the situation. This binary distro download may also create a
>  licensing problem for our Pardus distro. I guess this leaves the following
>  options:
>  1- package yum and febootstrap for Pardus and use them
>  2- create a "pabootstrap" package compatible with febootstrap and build a
>  Pardus appliance instead of fedora appliance
>  3- create a pre-cooked "compatible" pardus appliance image and use this one
>  
To chime in --

It may also be possible to come up with alternate distro-independent code
for building the appliance with Buildroot from the uClibc project [
http://buildroot.uclibc.org/]; I worked on a project similar to libguestfs
in the past, and buildroot worked reasonably well for me. One concern --
libraries used on host and guest may well not be compatible, so the
libguestfs daemon will probably need to be built within the buildroot
framework when building with this option.

(I have a very simple makefile sitting around somewhere which checks out a
known-good revision of buildroot from SVN, applies a few patches, and runs
an appliance build [my own appliance, not the libguestfs one]; I'm not
offering to duplicate the work for libguestfs, but I can try to dig it up
for reference).

Richard explained some reasons why he chose to use febootstrap as a response
to my first email to this list, which I remember only inasmuch as recalling
that I found those arguments compelling -- but if 'yall are interested in
putting together a distribution-independent build option which doesn't
require yum or friends, Buildroot might be one approach.

[Richard W.M. Jones]

On Fri, Jun 12, 2009 at 07:37:01AM -0500, Charles Duffy wrote:
>  Richard explained some reasons why he chose to use febootstrap as a
> response
>  to my first email to this list, 
Here ...

http://rwmj.wordpress.com/2009/03/20/why-not-use-a-minimal-distribution/

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

[Richard W.M. Jones]

On Thu, Jun 11, 2009 at 09:11:51PM +0200, Tim Tassonis wrote:
>  Daniel P. Berrange wrote:
> > On Thu, Jun 11, 2009 at 06:09:50PM +0200, Tim Tassonis wrote:
> >> Hi all
> >>
> >> Just came across libguestfs and, as a qemu user, this project really  
> >> sound fantastic to me.
> >>
> >> However, when I tried to compile the latest tarball, I failed,  
> >> mainly because of the inavalability of febootstrap, which obviously 
> >> does not exist under ubuntu, and cannot be installed due to the lack 
> >> of yum under ubuntu at least.
> >
> > Even though Debian/Ubunut use APT for their package mgmt system, there
> > should not be any problem installing the YUM + RPM libraries. This  
> > should allow febootstrap to be built & run, and not impact your host  
> > OS package mgmt
>
>  Yes, of course....but since it is mentioned that febootstrap is based on  
>  debootstrap, is there a technical reason for not just supporting  
>  debootstrap alternatively. I haven't got enough background regarding  
>  debootstrap/febootstrap and libguestfs to make a judgement about this  
>  though. 
I summarised the options here:

http://www.redhat.com/archives/fedora-virt/2009-May/msg00003.html

For the Debian package I went with option (1), since Debian already
has yum and rpm packaged.

>  But to require any distribution to install yum/rpm just for this
> library  
>   seems a bit intrusive to me. Requiring a specific distro packaging  
>  system for a package seems a bit distribution dependant to me. 
It's not like that.  Just because Debian ship yum doesn't mean that
anyone has to abandon apt.  yum under Debian is only used where
someone wants to install an RPM-based distro from a Debian host,
eg. as a chroot, or in a virtual machine, or (as in this case) to
build an appliance.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw

[Tim Tassonis]

Richard W.M. Jones wrote:
>  On Thu, Jun 11, 2009 at 09:11:51PM +0200, Tim Tassonis wrote:
> > Daniel P. Berrange wrote:
> >> On Thu, Jun 11, 2009 at 06:09:50PM +0200, Tim Tassonis wrote:
> >>> Hi all
> >>>
> > Yes, of course....but since it is mentioned that febootstrap is based on  
> > debootstrap, is there a technical reason for not just supporting  
> > debootstrap alternatively. I haven't got enough background regarding  
> > debootstrap/febootstrap and libguestfs to make a judgement about this  
> > though.
>  
>  I summarised the options here:
>  
>  http://www.redhat.com/archives/fedora-virt/2009-May/msg00003.html
>  
>  For the Debian package I went with option (1), since Debian already
>  has yum and rpm packaged. 
Thanks, I guess in an ideal world the best solution would be to have a 
configure option like

--image=[febootstrap|debootstrap|fixed]

or so, and then the package would be setup to use febootstrap on 
redhat-based systems, debootstrap on debian-based system and fixed to 
use a pre-build image.

As you say, it won't be too difficult, but clearly the patch doesn't 
write itself ...

But such a patch to libguestfs would be accepted in your opinion?

>  
> > But to require any distribution to install yum/rpm just for this library  
> >  seems a bit intrusive to me. Requiring a specific distro packaging  
> > system for a package seems a bit distribution dependant to me.
>  
>  It's not like that.  Just because Debian ship yum doesn't mean that
>  anyone has to abandon apt.  yum under Debian is only used where
>  someone wants to install an RPM-based distro from a Debian host,
>  eg. as a chroot, or in a virtual machine, or (as in this case) to
>  build an appliance. 
Sorry, I didn't mean that, it was clear to me that yum/rpm wouldn't 
replace apt/dpkg, it's just that I think the requirement of febootsrap / 
yum on a debian distribution is a bit problematic.


>  
>  Rich.
>

[Richard W.M. Jones]

On Fri, Jun 12, 2009 at 11:48:41AM +0200, Tim Tassonis wrote:
>  Richard W.M. Jones wrote:
> > On Thu, Jun 11, 2009 at 09:11:51PM +0200, Tim Tassonis wrote:
> >> Daniel P. Berrange wrote:
> >>> On Thu, Jun 11, 2009 at 06:09:50PM +0200, Tim Tassonis wrote:
> >>>> Hi all
> >>>>
> >> Yes, of course....but since it is mentioned that febootstrap is based 
> >> on  debootstrap, is there a technical reason for not just supporting  
> >> debootstrap alternatively. I haven't got enough background regarding  
> >> debootstrap/febootstrap and libguestfs to make a judgement about this 
> >>  though.
> >
> > I summarised the options here:
> >
> > http://www.redhat.com/archives/fedora-virt/2009-May/msg00003.html
> >
> > For the Debian package I went with option (1), since Debian already
> > has yum and rpm packaged.
>
>  Thanks, I guess in an ideal world the best solution would be to have a  
>  configure option like
>
>  --image=[febootstrap|debootstrap|fixed] 
Better if it was:

  --appliance=...

>  or so, and then the package would be setup to use febootstrap on  
>  redhat-based systems, debootstrap on debian-based system and fixed to  
>  use a pre-build image.
>
>  As you say, it won't be too difficult, but clearly the patch doesn't  
>  write itself ...
>
>  But such a patch to libguestfs would be accepted in your opinion? 
Definitely yes, but you'll also want to liase with Guido Gunter as
well, since he expressed an interest in doing this too.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v

[Richard W.M. Jones]

On Thu, Jun 11, 2009 at 06:09:50PM +0200, Tim Tassonis wrote:
>  Hi all
>
>  Just came across libguestfs and, as a qemu user, this project really  
>  sound fantastic to me.
>
>  However, when I tried to compile the latest tarball, I failed,  mainly  
>  because of the inavalability of febootstrap, which obviously does not  
>  exist under ubuntu, and cannot be installed due to the lack of yum under  
>  ubuntu at least. 
yum, rpm and febootstrap _are_ in Debian (as of last week), so it'll
be in Ubuntu soon enough.

I've got some packages of febootstrap and libguestfs which you can try
here:

http://www.annexia.org/tmp/debian/

The febootstrap package is reasonable.  The libguestfs packaging is a
bit crap, although it does work.

>  Is debian support planned, or is libguestfs designed to be a
> fedora-only  
>  project? 
We definitely want to support other distros (not just Debian).

Guido Gunter, who I think is on this list, contacted me about doing a
pure Debian port of libguestfs using debootstrap.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v

[Richard W.M. Jones]

BTW if anyone is confused about the architecture of libguestfs, it's
all explained in the manual:

http://libguestfs.org/guestfs.3.html#state_machine_and_low_level_event_api

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw