Bug#410039: No /usr/lib/xen folder so it's confusing other packages
Thomas Goirand [EMAIL PROTECTED] writes: Goswin von Brederlow wrote: Thomas Goirand [EMAIL PROTECTED] writes: Goswin von Brederlow wrote: 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. I understood that, for sure! 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? Maybe a script run at startup could check for the xen version that is running and make the appropriate symlink? Sure that could be in a xen-common package, for example... Is that what xen-utils-common does? Thomas /usr is (potentially) read-only. You can only write there during install time which is not enough. You would have to put a static link to /var/lib/xen and then have a dynamic link there or something. MfG Goswin Then what's the solution??? Thomas Beats me. The xen maintainer(s) have to make a choice there. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410039: No /usr/lib/xen folder so it's confusing other packages
Goswin von Brederlow wrote: Thomas Goirand [EMAIL PROTECTED] writes: Goswin von Brederlow wrote: 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. I understood that, for sure! 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? Maybe a script run at startup could check for the xen version that is running and make the appropriate symlink? Sure that could be in a xen-common package, for example... Is that what xen-utils-common does? Thomas /usr is (potentially) read-only. You can only write there during install time which is not enough. You would have to put a static link to /var/lib/xen and then have a dynamic link there or something. MfG Goswin Then what's the solution??? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410039: No /usr/lib/xen folder so it's confusing other packages
Thomas Goirand [EMAIL PROTECTED] writes: Goswin von Brederlow wrote: 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. I understood that, for sure! 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? Maybe a script run at startup could check for the xen version that is running and make the appropriate symlink? Sure that could be in a xen-common package, for example... Is that what xen-utils-common does? Thomas /usr is (potentially) read-only. You can only write there during install time which is not enough. You would have to put a static link to /var/lib/xen and then have a dynamic link there or something. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410039: No /usr/lib/xen folder so it's confusing other packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Goswin von Brederlow wrote: 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. I understood that, for sure! 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? Maybe a script run at startup could check for the xen version that is running and make the appropriate symlink? Sure that could be in a xen-common package, for example... Is that what xen-utils-common does? Thomas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF1buQl4M9yZjvmkkRAtTDAJ9TOYMKkyfvTSs1xjEpcFniyCbz7QCg4P0a eydB76cWR1OcL8U/zeRbSF0= =4SYo -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410039: No /usr/lib/xen folder so it's confusing other packages
Thomas GOIRAND [EMAIL PROTECTED] 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410039: No /usr/lib/xen folder so it's confusing other packages
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. 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. 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 -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.17.7 Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
