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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
