Re: [Xen-devel] ioemu

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Christoph Egger writes ("Re: [Xen-devel] ioemu"):
> On Monday 01 September 2008 12:05:36 Ian Jackson wrote:
> > I'm not sure I understand what checksum you're referring to here.  Is
> > it part of the NetBSD ports system ?  What does the ports system
> > expect ?
> 
> The checksum is part of the package in pkgsrc. It needs an URL where
> to download the source archive. After the download, the archive is verified
> against SHA1 and RMD160 checksums and against its size in bytes.

I've spoken to a local FreeBSD expert and we don't understand this
part of your complaint.  The ports system expects to start with a
tarball.  If you're trying to use the Xen 3.3.0 release, that tarball
could be the official release tarball.  If you say that that doesn't
work for you then you need some other tarball but there are no other
official tarballs.  In particular there are no official tarballs of
xen-unstable or qemu-xen-unstable.

Are you producing this tarball yourselves somehow ?  (hg archive
perhaps).  And your complaint is that its hash isn't always the same
when you use git ?  git-archive seems to produce reproduceable
tarballs for me. 

> It doesn't compile on BSD (and hasn't got the testing).

Does qemu upstream compile on BSD ?  I think you should be looking
into that if it's a problem.

> Our testing infrastructure is based on changeset numbers. From reading
> the number you immediately know is this an old or new changeset and
> you immediately know how many changesets are between two changesets.

Yes, then your test infrastructure will need to be taught how to deal
with git changeset ids - just like ours did.  It's not very difficult
and I'm sure you can cope.

> > I agree it is a shame that our official tarball isn't made entirely
> > mechanically.  If you would care to contribute a script that
> > reproduces the 3.3.0 tarball when dropped into the appropriate
> > xen-3.3-testing changeset, and also does a sane thing in currently
> > xen-unstable, we'll consider including it and using it next time.
> 
> So you are planning to also move the hypervisor to git in the
> middle/long run?

That doesn't seem to relate to the paragraph of mine you quote, but:

This is not my decision to make, but I expect that Xen will stay with
hg for quite a while and I don't think it should change soon.

The situation with Xen is much less fraught than that with qemu.
After all Xen does not have three or four strange semi-forks, whereas
qemu does (ioemu is one), Xen upstream is already using a dvcs rather
than svn, etc.  So use of git's features for dealing with bad
situations much less necessary with Xen.  That means that git's
downsides (chiefly, the catastrophic and constantly changing UI) are a
decisive factor - and of course there is no particular incentive to
change.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel