Bug#410039: No /usr/lib/xen folder so it's confusing other packages
Thomas GOIRAND <thomas@goirand.fr> writes:
> Package: linux-image-2.6-xen-686
> Severity: wishlist
>
> Hello,
>
> Our package, dtc-xen, uses /usr/lib/python/xen installed by the
> normal xen source package using make install. With this package,
> there is no such folder, but instead something with version
> number like this: /usr/lib/xen-3.0.3-1/lib/python. So we cannot
> include the xen python bindings for xen.xm that we use to start
> and stop a VM. Of course, there is no error when using the
> source version of xen from xensource.com. I highly think
> that not having this /usr/lib/python/xen folder under the
> Debian package is really problematic.
The problem is that multiple xen versions (3.0-unstable, 3.0.3, 3.0.4)
can be installed and they are incompatible with each other. If each
one contained /usr/lib/python/xen then the packages would have to
conflict.
What you need is a common package that contains wrapper scripts in
/usr/lib/python/xen that will pick the right
/usr/lib/xen-VERSION/lib/python subdir applicable to the running xen
version.
Maybe xen-utils-common is what you should be using?
> As there would be a problem to just insert a symlink in the
> package itself (diversion problems when upgrading or when you
> want to have both versions installed at the same time), my
> suggestion is that the postinst of the package creates a
> symlink in /usr/lib/python/xen so that it always works. Note
> that our package (dtc-xen) will not care if it's not the
> corresponding kernel that is started, I believe, but this
> would for sure solve our issues.
What if you remove the package? The postrm would remove the
symlink. But it would not create a symlink to an alternative version
normaly.
This sounds more like a job for update-alternatives but can you use
that on directories? And only if it truely doesn't matter what version
you end up with.
> I'd appreciate A LOT if this was fixed. Note that I have filed
> a bug only for this i686 version, but of course, the same
> problem occurs when running on amd64 and other images.
>
> Best regards and thanks for this work,
>
> Thomas Goirand
MfG
Goswin
Reply to: