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

[Guido Günther]

On Sun, Apr 15, 2012 at 04:43:06AM +0800, Thomas Goirand wrote:
> On 04/14/2012 05:52 PM, Bastian Blank wrote:
> > You failed to describe, why you want it.
> 
> Hi Bastian,
> 
> If Guido failed, let me try then, since this impacted me multiple times
> as well. Hoping that this time, I'll succeed in convincing you.
> 
> What we need is a /usr/lib/xen so that Debian isn't an exception, and
> that in the general case (eg: in all other cases but with your package),
> the folder is there. Every other distributions (Xen from upstream
> sources, Fedora, Gentoo, Arch, CentOS, and maybe more) have this folder.
> 
> 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.
> 
> 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).
> 
> For example, someone might want to access things under /usr/lib/xen/bin,
> or the hvmloader. Or libxenlight.so (which is a public API that isn't in
> /usr/lib, so it might need a RPATH, which here is specific to Debian).
> 
> If you want to achieve this by dropping the use of Xen visioning, then
> I'm all for it, as I don't think it adds anything (unlike the kernel,
> Xen doesn't hold drivers that sometimes would fail, and an upgrade to a
> newer version should always work(tm), and I don't see any cases where we
> would need to have 2 versions of Xen installed on a system at any given
> time). But any ways is ok as long as we can use /usr/lib/xen to find
> what we are supposed to expect in there.

This sums is up very well. Thanks!
Cheers,
 --Guido