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

[Guido Trotter]

On Sat, Feb 25, 2006 at 01:48:13PM +0100, Ralph Passgang wrote:

Hi,

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

Right! I agree... For now let's leave it like this, and fix in one of the next
versions!

Are you sure adam's was a solution and not just a bug?

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

Well... That was my point... On one hand we need to distribute a patch that we
know works, and that's the one for linux-2.6.12... On the other hand, though, we
cannot ignore a request of the Release Manager not to ship it in a package if it
doesn't apply to a debian kernel... That was why I proposed distributing it on
Alioth and saying that in the README...

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

right!

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

right, again!

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

Yep!

Guido