[Pkg-xen-devel] Bug#536174: Bug#536174: Bug#536174: Bug#536174: xen-utils-3.4: pygrub searches for filesystem plugins at the wrong path

[Thomas Goirand]

Bastian Blank wrote:
> On Sun, Jul 19, 2009 at 04:25:58AM +0800, Thomas Goirand wrote:
>> Bastian Blank wrote:
>>> On Fri, Jul 17, 2009 at 08:08:48PM +0800, Thomas Goirand wrote:
>>> What is "numerous software" and what are they doing with this internal
>>> und unstable interfaces?
>> Namely: enomalism, dtc-xen (our software). We are currently getting away
>> from it, and build a cleaner code using libvirt, but still ... There
>> must be some other software as well, I remember at least a 3rd one needs
>> it, but can't remember it's name.
> 
> And what do they use? xen.xm? xen.lowlevel?

At least: xen.xm.main, xen.xm.main.server.xend.domain().

> No, Xen have several definitions, where it tries to install to by
> default. /usr/lib/xen is only one. So, if you think this should exist,
> please elaborate the behaviour of it, including all constraints.
> 
> Bastian

One VERY important one, is that there is /usr/lib/xen/boot/hvmloader.
It's there in all distributions, but in Debian, it's in
/usr/lib/xen-VERSION/boot/hvmloader. It's a *moving target* in Debian.

Any software that wish to be a manager (that creates and deletes VMs)
for Xen in Debian can't predict where is the hvmloader to point to in
the VM startup configuration file /etc/xen. At least, that one is a very
valid reason, if you don't think the python lib is one. You may say that
there's /etc/alternatives/xen-default, but WHY would we have something
that specific in Debian? Why can't we just have /usr/lib/xen like
everyone else? Just a very small symlink solves this issue for ALL
software in Debian, instead of patching them one by one.

Thomas