This is quick and from memory, but it covers the basics. Sorry about
the duplicates. My hope is this will be a friendly list, so people will
be as open on it as they are with me. However, I have sorted them by
frequency, so if you want an idea of what "users" seem to be interested
in, this is what I've seen.<br>
<br>
1) Kernel Images<br>
<br>
This is the big fun. I know why these may never end up in pure debian.
It also seems that from the feedback I've gotten, the kernels are what
most help people get going quickly.<br>
<br>
For now, I've discussed maintaining three versions (and do) but have
told everybody not to ever expect this in stable. Basically, people
seem to want...<br>
<br>
* The debian-standard kernel, modular, which supports almost everything<br>
* A clean kernel, which boots on base hardware, and is close
enough to the base xen config that you can post to the xen lists and
get feedback<br>
* A mid-way kernel. Most demands are for support of all file systems, and networking modules.<br>
<br>
(FULL DISCLOSURE: I spend a lot of time doing custom xen/debian kernels now, so my perspective is probably skewed)<br>
<br>
2) /lib/tls <br>
We all know about this.<br>
<br>
2) Grub menu entries<br>
People used to debian are used to update-grub just working. My
workaround is kind of awkward, but xen boot stanzas are complex. I'd
love to discuss.<br>
<br>
3) Init scripts<br>
For example, hang on shutdowns (in xen 2) are not normal behavior; if the domU won't die, the system won't shut down.<br>
<br>
4) Network scripts<br>
<br>
More transparency in the routing vs. bridging setups<br>
<br>
5) xen-system<br>
<br>
My packages have a "xen-system" meta-package. I've seen feedback both
ways. Some people are far enough that they know how to make the parts
work. Some people just want to do a quick benchmark. If the
meta-package doesn't end up in debian, I'll probably have to maintain
the "meta fiddly bits" for those who want them.<br>
<br>
6) Installer<br>
<br>
Did this on a lark. Spent way to much time learning about the details.
Got used more than I would ever have thought. Currently on
source-forge. Probably not directly part of this, but it seems to be of
interest to those who would like to see greater acceptance of Xen in
mainstream.<br>
<br>
7) Upgrade<br>
<br>
This is just me, but I spent many a sleepless night between 2.0.6 and
2.0.7 once I realized that people were actually using our stuff. Xen
upgrades will never work like other upgrades. At least in 2, I could
never get a way to get the new version to work without a reboot, and
it's obvious that regardless, the domU needs to be shut down. Most
people thought I was a nutcase for worrying about this so much, but I
can think of few (to no) other situations that when you do an "apt-get
dist-upgrade" you have to reboot, so I'm not sure the best way to deal
with this.<br>
<br>
8) Life without xend<br>
<br>
This is also partially me, but I've been in contact with the vmtools
people, and we use them in some cases, so it's good to keep in mind the
various dependencies (what you need to boot, vs. what you need to start
a domu).<br>
<br>
That's it off the top of my head. I'll post a few more if I find something I've forgotten, or if people ask for proof ;)<br>
<br>
-yentlsoup<br><br><div><span class="gmail_quote">On 2/15/06, <b class="gmail_sendername">Jeremy T. Bouse [c]</b> <<a href="mailto:jbouse@debian.org">jbouse@debian.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Actually I think this information could be handy as we do want to<br>make the package to serve the users needs not necessarially just what we<br>want.<br><br> Regards,<br> Jeremy<br><br></blockquote></div><br>