[Pkg-xen-devel] More on our TODO lit

[Ralph Passgang]

Am Samstag, 25. Februar 2006 09:58 schrieb Julien Danjou:
> On Sat, Feb 25, 2006 at 08:58:07AM +0100, Guido Trotter wrote:
> > 1. xen-utils:
> > 	Right now domains get shut down on upgrade... This is ok in a 2.0 -> 3.0
> > 	scenario, but it's not in a 3.0.1 -> 3.0.2, where we could avoid that,
> > 	probably! Should we perhaps try to avoid that, hacking a bit on the
> > 	maintainer scripts?
>
> Using debconf probably, some package like openvpn (the first I can
> remember) ask about being restarted during upgraded, or not.

The problem is that if someone updates xen it's normaly not needed to have the 
domUs stopped before upgrading, but on the other hand if someone updates 
major releases he cannot use the new userspace tools until he rebooted, so in 
this scenario it might be better to stop domUs before upgrading.

stopping domUs is also important when someone removes the xen packages, 
because without userspace tools he cannot control his domUs anymore.

adams solution was to stop xend before xendomains, because of that xendomains 
couldn't shutdown domains on a upgrade. But this produced some ugly errors on 
upgrading and would also be a failure if someone removes the xen packages.

So we need maintainer scripts with more logic to detect what is actually 
happening and to react correctly on that, or we should leave it (at least for 
now) like it's handled now. It's not really optimal, but better adams way of 
dealing with this (imho).

using debconf for asking what the users wants is also alternative...

> > 2. kernel-patch-xen:
> > 	Steve says the policy is not to distribute it unless it applies to the
> > 	debian kernel... Shall we withdraw it? We can still have the diff
> > 	perhaps published on alioth (as there it's more official than in some
> > 	website of ours) and document this in README, for people who prefer to
> > 	roll their own kernel! What to you think? In that case we can leave the
> > 	patch in the repo, and just move it out of the debian/ directory...
>
> Steve's right, unfortunately... So what's better for our users?

for users it's better to have a patch that works, even if it's not for a 
standard debian kernel. We simply cannot produce patches for any kernel 
versions, so we have to stick with xen's upstream and so for now with 2.6.12
(.6).

What can we do? Nothing really. I think we should ignore that for now. If the 
xen arch gets merged in the linux-tree in future we don't need to do this 
anymore, but until then we have no real alternative, haven't we?

> > 3. -unstable:
> > 	Steve says it's useless to distribute both unstable and 3.0, Bastian and
> > 	Jeremy would like to... For me, no problem at all, but we'll have to
> > 	sort this out!
>
> I don't really care. What I know is that I'm going to use a stable
> version for production systems :-)

I want a stable (aka testing) version at least. Providing -unstable is not 
important for me, but we can of course do that too. In generel there shoudn't 
be much needed to have a unstable xen system packaged with our debian files.

But -unstable is a developer tree, so we should definitly not use that as 
default! It is also chaning very fast and has from time to time really 
stability issues or isn't even compliing...

> > 4. glibc:
> > 	Contacting the glibc team is still on our TODO list, and can be done
> > 	after the release!
>
> *ack*

*ack too*

> > 5. kernel:
> > 	Sorting things out with Bastian and the kernel team still pending...
>
> Yes, but other people from the kernel team seems reasonable.
> If they could care of dom0/domU kernel, it will be great.

I also think that would be the best way to go!

> > 6. wnpp:
> > 	Should we file an ITA there, now or in one day or two, as consensus on
> > 	debian-devel seems we should adopt the package, but there are still a
> > 	couple of things that we might want to wait for before uploading!
>
> I don't think we should open an ITA since there is no O no bug report.
> That's a take over, I don't think there is a clear procedure. ;)

this might get a takeover of a takeover, so that is at least not definied 
anywhere .)