Daniel P. Berrange writes ("Re: [Fedora-xen] Preview Xen 3.2 rc*
packages"):
[stuff]
Thanks for your helpful comments.
On Fri, Dec 21, 2007 at 04:30:36PM +0000, Ian Jackson wrote:
> xen-qemu-bootmenu.patch
> pygrub-manykernels.patch
There were both written by Jeremy, so copyright Red Hat. I'll get them
posted upstream.
I see you've done that now, thanks. I don't know if they'll make
3.2.0 at this stage but I'll include them in my release packages if
not.
We are going to be putting the hypervisor in a
'xen-hypervisor' package
for F9, so it might be work folowing same practice.
Right, yes, I'll see about doing the same.
> I have not included xen-net-bridge.patch which seemed quite a
> surprising set of changes to me.
Most of those, if not all, should be upstream in 3.2.0
I don't think so but if you think so then fine - I'm happiest here
just shipping the upstream code unaltered.
> I was rather puzzled by the part of xen-initscript.patch which
removes
> most of xend's startup code. I agree that xend's arrangements are not
> entirely ideal but is there really much to be gained by making that
> changes, which obviously makes the patchset much more fragile ?
The reason for this is that the upstream changset did not play nicely
with standard Fedora init script good practice. IMHO duplicating stuff
that is already provided by standard initscript shell functions in
python is a bad idea, hence we killed it. I did post these changes
upstream for review at the time by they weren't incporated. Should be
in the archives somewhere....
Hmm. I have some sympathy with this line of reasoning but there are
some subtleties to do with the lifetimes of the various daemons and of
course it might happen that there would be a reorganisation of of
these daemons (into a different set of processes).
I think it's better to regard these as `parts' of xend, rather than
individual daemons in their own right. That also means that when Xen
is ported to a new host OS, less work is needed to adapt the daemon
startup to conform to the host's arrangements.
In any case the upstream 3.2.0 won't change in this area at this
stage. It's probably best of the packages I make for Fedora use your
setup (particularly since otherwise I'd have to tack a hatchet to the
existing FC7 init scripts).
FYI, you might want to check the rawhide spec file - for pre-release
builds
we are standardizing on a numbering format of:
'xen-3.2.0-0.fc8.rc3.dev16606'
I'll take a look at the rawhide spec file, and your Fedora 9 version,
but mainly for illumination than code. I think the upstream-provided
packages of 3.2.0 for fc8 ought to be based on the 3.1.x fc8 packages.
NB, the leading the '0' in the release number ensures the
upgrade path
to the final official 3.2.0-1.fc9 package.
Right, I'll do that next time.
Daniel P. Berrange writes ("Re: [Fedora-xen] Preview Xen 3.2 rc* packages"):
FYI, my 3.2.0 RPMs for Fedora 9 are currently in a branch of Fedora
CVS called 'private-berrange-xen-unstable' viewable here: [...]
Thanks.
I've not decided yet on wether to name the hypervisor
'/boot/xen.gz' or
include a full version '/boot/xen-3.2.0.gz', or version + release
'/boot/xen-3.2.0-1.fc9'. I think i'll probably go for 'xen-3.2.0.gz'
I would definitely include the hypervisor version in future; I'm less
sure about the package version.
Debian have a very nice arrangement which lets you co-install
different hypervisor and tools versions, and then effectively
dual-boot. Unfortunately their patches are very intrusive so that
won't be in 3.2.0, but I think we certainly want to move in that
direction upstream in the future (probably with different changes to
achieve the same effect, rather than trying to import and redact
Debian's patchset).
Daniel P. Berrange writes ("Re: [Fedora-xen] Preview Xen 3.2 rc* packages"):
Can I request that you include something in the release number to
indicate
that these are XenSource provided RPMs - just using 'fc8' will lead to
confusion with the base Fedora provide RPMs. Either add 'xs' after the
initial release digit, or tag it on after the %dist tag, eg one of
xen-3.1.9-0xs.fc8.i386.rpm
xen-3.1.9-0.fc8.xs1.i386.rpm
Of course. I should have done that to start with, really.
This ensures that if we get Bug reports it'll be clear which RPMs
are being
used.
Right.
Regards,
Ian.