[Pkg-xen-devel] Bug#668641: Please add a symlink /usr/lib/xen -> /usr/lib/xen-default

[Thomas Goirand]

Hi,

Thanks for your time replying.

On 04/16/2012 01:51 AM, Bastian Blank wrote:
> On Sun, Apr 15, 2012 at 04:43:06AM +0800, Thomas Goirand wrote:
>> When designing a software for Xen, we don't want to have to handle a
>> specific case for Debian, where /usr/lib/xen is called another way. We
>> don't want either to have to patch some upstream code that may be using
>> /usr/lib/xen if we want to package it in Debian.
> 
> /usr/lib/xen does not describe a public interface.
> 
>> Having /usr/lib/xen being the currently running hypervisor is what we
>> want here (eg: we might need it at runtime, I don't see any cases where
>> we would need it at build time, but I might be wrong).
> 
> This is not possible. /usr have to be considered read-only.

The only thing we need to fix the situation is:
ln -s xen-default /usr/lib/xen

and that's it! No need to write things in /usr. This is a one-line fix
in your packaging!

>> For example, someone might want to access things under /usr/lib/xen/bin,
>> or the hvmloader.
> 
> hvmloader and other stuff in the configs should be addressed with
> relative paths.

Could you explain this a bit more? Do you mean that, in a domU startup
file, we should just write:
kernel = "hvmloader"
builder= "hvm"

without the full path? Does this work as well with pygrub? Can I write:
bootloader = "pygrub"

My understanding was that we are currently forced into writing:
bootloader = '/usr/lib/xen-default/bin/pygrub'

which is Debian specific... Am I wrong?

>>                   Or libxenlight.so
> 
> libxenlight.so needs to be the exact match, it does not include an
> abiname.
> 
>>                                     (which is a public API that isn't in
>> /usr/lib, so it might need a RPATH, which here is specific to Debian).
> 
> Stuff outside of the normal library search path is not public. So
> libxenlight is not a public interface in Debian.

My understanding is that, at least when Xen 4.2 will be out, libxl will
be considered a public interface. Ian Campbell wrote in xen-devel:

"we would like [Xen] 4.2 to define a stable API which downstream's can
start to rely on not changing."

So if currently you may be right, Xen is taking the direction to have
libxl as a public interface. Maybe Debian should ship libxenlight.so in
the search path and have it with ABI versions... Or do you think this
shouldn't happen before Xen 4.2? Thoughts?

Cheers,

Thomas