On 12/19/2010 08:48 AM, Vagrant Cascadian wrote: > On Fri, Dec 10, 2010 at 04:05:19PM +0800, Thomas Goirand wrote: >> The symlink creation should be removed completely, because it's >> preventing upgrades from Lenny. > > seeing as this is reported by the maintainer, i'm just trying to figure out in > more detail what this bug is about in case others stumble upon this as well... > > correct me if i'm wrong, but i think the symlink referred to is in the > postinst, which includes a long rant from an unknown person, that doesn't > really clarify what the symlink is really even trying to solve: > > #!/bin/sh > > set -e > > # Everyone rejected my repeated requests saying it was useless, so I will > do it > # in this package, because I'm tired that Debian has no support for the > # standard path that works EVERYWHERE ELSE, then creating compatibility > # and versionning issues when the solution is so obvious. > # 1/ If someone do not agree with the following, then please start a > discussion > # with your motivated arguments against this on debian-de...@l.d.o. > # 2/ If someone claims that this should be made in another package, I do > agree. > # But then convince the other maintainers that are maintaining the > # hypervisor, not me, I do agree with that point. > # In the mean time, I'll put this in all packages I believe need access to > the > # standard path. > if ! [ -e /usr/lib/xen ] ; then > ln -s /etc/alternatives/xen-default /usr/lib/xen > fi > > exit 0
What is happening is that in every other distribution, and when you install Xen from source, there's a /usr/lib/xen containing various tools and libs that one might need. In Debian, it's made in /usr/lib/xen-4.0 for example. This creates compatibility issues for some software. Fore example, if you want to create a VM with VT-x feature, you would do: kernel = "/usr/lib/xen/boot/hvmloader" builder = 'hvm' memory = 512 device_model='/usr/lib/xen/bin/qemu-dm' But in Debian, you are forced into doing: kernel = "/usr/lib/xen-4.0/boot/hvmloader" builder = 'hvm' memory = 512 device_model='/usr/lib/xen-4.0/bin/qemu-dm' which to me, isn't right. Then the issue is that, on one of my servers, upgrading failed because of the creation of this symlink. I think it fails because I didn't handle things through update-alternatives (but not sure, I didn't push the investigations so far). Because I don't want this to happen to someone else running Squeeze, I thought I should open a bug against my own package, and have the symlink creation killed altogether, which is safer than just create something that could be done by the admin. > when triggered, this ends up creating a dead symlink for /usr/lib/xen that > points to /etc/alternatives/xen-default, which could result in problems since > nothing apparently ensures that /etc/alternatives/xen-default actually exists > and points to a directory. Yes, that's the issue. > it also seems to be a backwards use of /etc/alternatives, as normally there is > a symlink such as /usr/bin/foo that points to /etc/alternatives/foo which then > links to one of the possible implementations of "foo" such as /usr/bin/foo-bar > or /usr/bin/foo-baz. if it really is a valid use-case, it should probably be > using update-alternatives instead of manually calling "ln -s". Correct, I didn't handle it the way I should have. But at the end of the day, my thinking is that the symlink creation should be removed completely, and left to the administrator of the server. I'm not really sure of that though, and I am open to others view on this. Please let me know what you think! Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
