[Pkg-xen-devel] Choosing which toolstack to use with debconf

[Thomas Goirand]

On 12/24/2011 11:16 PM, Ian Campbell wrote:
> In any case none of that is incompatible with requiring people to
> configure their primary $TOOLSTACK.

I don't mind taking care of that part. Also, I could write a wrapper, so
that we still can use "xm" when xl is selected, as we discussed earlier,
but I'd like to discuss first what I should implement, since otherwise
I'll get to implement things, we wont agree, and we'll waste so much time...

So, my proposal is this one.

- By default, have "xl" as the default value for $TOOLSTACK, since that
is the recommended thing to use in Xen.
- Have debconf select between these 3 values: xm, xl, xe
- If xm is used, but xl selected, have a wrapper to use xl (so in this
way, we keep backward compatibility), but display a message on the
standard error.
- If xl is used, but xm is selected, *FAIL* (eg: exit(1)), and display a
message on the standard output.
- If something else than xm is in $TOOLSTACK, do not start xend. Also,
check if xend is running directly in xe / xl, and fail with an error
message if it is.

Please discuss if you'd like to see something lese than xm,xl,xe as
values in $TOOLSTACK, knowing that this has my preference over plain
names like xend,xenlight,xenapi which I believe are more error-prone:
- Should we write "xl", or "xenlight"?
- If it's "xl", then why not "xm"?
- If we use "xend" instead of "xm", then should I type "xapi", or
"xen-api" or "xcp"?

So if you don't mind, just xm,xl,xe will be better! Anyway, this will
have to be written as comments in the config file.

Please let me know if the above is ok, then I'll implement. Also,
Bastian, please let me know how you think the postinst script should
write /etc/default/xen. You just wrote that overwriting the config file
is wrong, but you still didn't write here what you think should be. My
reading of the policy is that the only thing we should care about is
making sure that what the admin has configured by hand stay as
configured, but I don't think the policy forbids to overwrite config
files, which I think is the safest method (grep, sed and friends could
have nasty results).

Thomas