[xen-tools] Re: Multiple role scripts ..

[C.J. Adams-Collier]

Sorry for the confusion.  I actually think that both tests are useful.
 One tests the copy target, one tests the debootstrap target.

On a different note, I've attached a patch that may fix the problem
that was causing the Log.pm error.

On 9/24/07, Steve Kemp <steve at steve.org.uk> wrote:
> On Mon Sep 24, 2007 at 13:24:27 -0700, C.J. Adams-Collier wrote:
>
> > I didn't mean a *working* OS.  I meant something that would allow
> > xen-create-image to complete its run with a $? == 0 status.  I bet we
> > can fit this in 10M.  But still, increasing the distribution by 10M is
> > not an optimal situation.
>
>   Given that /etc/ contains the only real source of files that
>  would be changed I'd be happy enough to have $dist.etc.tar.gz
>  as an HTTP download, or similar.
>
> > >   --install-method=debootstrap --install-source=http://us.debian...
> >
> > I disagree.  In order to create a testable situation, we need a
> > control environment.
>
>   I agree.
>
>   My understanding of your suggestion was that we would have:
>
>     1. A minimal install which would be configured via xen-tools.
>
>     2. A static MANIFEST file which would contain the results
>        of running an install which we'd test against.
>
>   From that point of view running --install-method=debootstrap
>  would allow the minimal install to be completed and compared
>  against the static MANIFEST you described.
>
> > debootstrap will potentially generate a different filesystem every
> > time it is run.
>
>   No it wouldn't.  (OK timestamps will be different, but everything
>  else will be the same.)
>
>   If you're just going to use a static static collection of files
>  then the test becomes meaningless.
>
> > If we have a tarball that we populate, we can create
> > a controlled situation that we can test against.  Not to mention,
> > debootstrap creates *many* more files than are strictly necessary for
> > xen-create-image to successfully run.
>
>   True, but a test is a test.  And the full install is a useful
>  one which doesn't require any large download added.
>
> > it *is* important to have a test case for debootstrap as well, of
> > course.  I don't think we should use the live debian servers for this,
> > however.  In order to create a control, we should take a snapshot of
> > the mirror and strip it down to only those .deb files required for
> > debootstrap to complete successfully.  We should use this control
> > mirror as the argument to --install-source.  This is still not
> > strictly a control situation, however, since the version of
> > debootstrap on the builder's machine may vary.
>
>   I see two ways forward:
>
>     1.  Have a small tarball of just:
>
>         /dev/
>         /etc/
>
>        That could be untarred and manipulated woth xen-create-image.
>       This will allow us to test that $prefix/etc/hostname is setup,
>       that $prefix/etc/inittab is setup, etc.
>
>
>     2.  Test against http://debian.org, running a full debootstrap
>        install.  This will be simple to test, and simple to code,
>        but will be much slower and can't be done offline.
>
>   You seem to be suggesting the first approach, I was interested
>   in the second - but I think as soon as we reach the point where
>   we're tarring up *debian packages* we might as well not bother
>   and go straight for the second.
>
> Steve
> --
> # Commercial Debian GNU/Linux Support
> http://www.linux-administration.org/
>
>
>
>


-- 
moo.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20070925-a.diff
Type: text/x-patch
Size: 1462 bytes
Desc: not available
URL: <http://sym.noone.org/pipermail/xen-tools-discuss/attachments/20070925/52d7bdd8/attachment.bin>