On Fri, Feb 10, 2006 at 12:48:21PM +0100, Andreas Jochens wrote: > your solution looks indeed nicer that the "patch to the patch" to fix > the linker path. > > However, there is one (probably not really important) thing > which I do not like: > > The patch will cause a lot of symlinks which currently point from > '/usr/lib/lib*.so.*' to '/lib/lib*.so.*' to be changed to point > to '/lib64/lib*.so.*' instead, e.g. > > lrwxrwxrwx 1 root root 15 Feb 8 05:58 librt.so -> /lib/librt.so.1 > > would become > > lrwxrwxrwx 1 root root 15 Feb 8 05:58 librt.so -> /lib64/librt.so.1
Oh, I haven't thought of that. I tested the resulting binary, but I haven't looked at the links. > Currently, the /lib64 directory symlink is used _only_ to provide the > correct linker path. Nothing else in the distribution references > the /lib64 directory, i.e. everything is (or at least should > be) installed in /lib and nothing depends on the /lib64 symlink > with the single exception of the linker path. That let me ask about having /lib64 as the real directory, and /lib as a symlink. At least it would make the /lib64 directory compliant with the FHS. Do you know what kind of problem that could cause, other than a complex upgrade? > I think it would be good to keep it that way and to let the symlinks > point to '/lib/lib*.so.*' as they do now. > Do you perhaps know of a simple way to achive this within your approach? I think that's possible, I'll try do find a solution. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `- people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
