[Pkg-xen-devel] Bug#507186: Bug#507186: xen-utils-3.2-1 doesn't package the xen python library correctly

Thomas Goirand thomas at goirand.fr
Sat Nov 29 00:39:33 UTC 2008

Hi Bastian,

First, thanks a lot for answering that fast to my report.

Second, I'm quite sorry, but I don't agree AT ALL with your point of
view on this situation. I don't agree as well with the "wontfix" when I
gave you a very simple way of fixing, and the "minor".

Bastian Blank wrote:
>>              The only way to fix it is to do:
> You are free to extend the search path in your application.

With a moving target (eg: version numbers changing as the releases are
coming)? Are you serious?

>> xen-utils-3.2-1 should in fact use the folder /usr/lib/python2.5/site-packages,
>> and not /usr/lib/xen-3.2.1.
> No.

Install Xen from source (not from the debian package) and see that it's
in the python search path. Now you just say "no", I'd like to understand
WHY you say no.

>>                             By the way, there is no reason why somebody would
>> want to have 2 version of xen-utils installed at the same time, on a single
>> computer, IMHO (unless to do some tests, which is not a reason that apply to a
>> distribution like Debian).
> There are.

Please list them. Give me a use case...

>> Anyway what is the choice of the pkg-xen-devel team, something has to be done
>> to fix the current situation, because it's breaking other packages that are
>> using Xen and its python files.
> Nothing which resides in /usr/lib/xen-* is stable API/ABI from our point
> of view.

Let me give a simple example. If you want to do "xm start" on the shell,
this spawns yet-another-process. Instead, if I just import the xm python
module in my daemon, then it saves me a fork and I can use threads. Even
if this is not an API, I don't see how this could not work in the
future. Do you really see Xen upstream removing the xm command?

Also, people like me and the author of Enomalisme for example, wrote
this before there was that XML-RPC API. At the time, there was no other
choice. So if we want to stay backward compatible, that's the only reason.

Also, if the author of Xen have decided to send their python code in the
python search path, why would YOU decide that it shouldn't be the case?

Also, there are all sorts of things you can't do with the XML RPC API.

> Setting it to wontfix because I don't see how this could be changed.

I just gave you an EASY solution, what's wrong with it?


More information about the Pkg-xen-devel mailing list