<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 11 Jul 2011, at 20:03, Bastian Blank wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On Tue, Jul 12, 2011 at 02:38:54AM +0800, Thomas Goirand wrote:<br><blockquote type="cite">1/ blktap(-ko)<br></blockquote><blockquote type="cite">How much this blktap and blktap-ko differ from the one in the "normal"<br></blockquote><blockquote type="cite">pvops kernel?<br></blockquote><br>blktap was never and will never be accepted into the kernel.<br><font class="Apple-style-span" color="#000000"><font class="Apple-style-span" color="#144FAE"><br></font></font></div></blockquote><blockquote type="cite"><div><blockquote type="cite">2/ xen-api binary names<br></blockquote><blockquote type="cite">xen-api-xe<br></blockquote><blockquote type="cite">xen-api-www<br></blockquote><blockquote type="cite">xen-api-tests<br></blockquote><blockquote type="cite">xen-api-squeezed<br></blockquote><blockquote type="cite">xen-api-v6d<br></blockquote><blockquote type="cite">xen-api-xenops<br></blockquote><br>So most of them can be used independent?<br><br></div></blockquote><div><br></div><div>xen-api-xe, xen-api-squeezed and xen-api-xenops could conceivably be used independently, although xapi is currently the only consumer. For situations like this, is there a policy? I don't particularly mind one way or another.</div><div><br></div><div>xen-api-www and xen-api-tests would be optional packages that you may not want to install.</div><br><blockquote type="cite"><div><blockquote type="cite">libxen-api-client<br></blockquote><blockquote type="cite">libxen-api-datamodel<br></blockquote><br>Missing ABI version.<br><br></div></blockquote><blockquote type="cite"><div><blockquote type="cite">libxen-api-client-dev<br></blockquote><blockquote type="cite">libxen-api-datamodel-dev<br></blockquote><br>Why?<br><br></div></blockquote><div><br></div><div>I believe these should be more like 'libxen-api-client-ocaml-dev' and 'libxen-api-datamodel-ocaml-dev' - they are both pure ocaml libraries, and should be packaged according to this: <a href="http://pkg-ocaml-maint.alioth.debian.org/ocaml_packaging_policy.html/c305.html">http://pkg-ocaml-maint.alioth.debian.org/ocaml_packaging_policy.html/c305.html</a>  -- since they are pure bytecode, there's no need for non -dev packages.</div><br><blockquote type="cite"><div><blockquote type="cite">4/ Build-Depends<br></blockquote><blockquote type="cite">For the moment, I have the following:<br></blockquote><blockquote type="cite">Build-Depends: debhelper (>= 8), libpam-ocaml-dev, texlive-base, omake,<br></blockquote><blockquote type="cite">ocaml-findlib, libxmlm-ocaml-dev, libtype-conv-camlp4-dev, libxen-dev,<br></blockquote><blockquote type="cite">zlib1g-dev<br></blockquote><br>If you build-depend on libxen-dev, you have to include the version of<br>the underlying Xen somewhere.<br><br><blockquote type="cite">5/ Naming<br></blockquote><blockquote type="cite">Should we use "xen-api" or "xapi" ? To me "xen-api" seems more relevant,<br></blockquote><blockquote type="cite">and might avoid clashes with X-Window. What do you think?<br></blockquote><br>The X prefix means X11.<br><br></div></blockquote><div><br></div><div>xen-api seems perfectly reasonable to me, although the main xen-api-serving binary is called xapi.</div><br><blockquote type="cite"><div>Bastian<br><br>-- <br>I'm a soldier, not a diplomat.  I can only tell the truth.<br><span class="Apple-tab-span" style="white-space:pre">     </span><span class="Apple-tab-span" style="white-space:pre">    </span>-- Kirk, "Errand of Mercy", stardate 3198.9<br></div></blockquote></div><br></body></html>