* Andreas Jochens (aj@andaco.de) wrote: > On 04-May-08 12:39, Stephen Frost wrote: > > Erm, AIUI you'd have to recompile everything if you change the location > > of the interpreter. > > If we would not provide a compatibility symlink at the old location, > we would have to recompile everything. Since there is no > official archive yet, even that would be possible. I compiled about Sure, but it'd kind of suck, imv. > > Erm, that assumes they will. I wouldn't exactly bet on it. :) > > Of course, you are right. However, if Debian implements a good > working multiarch solution this will certainly make decisions easier. Right, and there's been alot of discussion and there are people working on what seems to be a more acceptable solution to people in general. > > How does making the actual interpreter a symlink satisfy the standard > > where having the directory symlink'd doesn't? > > We could also put the interpreter directly in a real '/lib64' directory > without any symlinks. This would satisfy the standards. I have tried > this and it doesn't seem to make any problems in the 'pure64' context. Well, sure, any of them will work but I figure for pure64 having the /lib64 -> /lib symlink is probably the best/easiest solution. > What solution to the '/lib64' issue would you prefer? It doesn't need to be solved for pure64. For multiarch, there's already a different and better solution that gets rid of /lib64 entirely except as a symlink for the loader. > I think we have basically three options at the moment: > > 1. Make /lib64 a symlink to /lib (and do not install any 32bit libraries) > This is what 'pure64' does now. (Gentoo does the same, so at least we > would not be alone with this approach). > > 2. Make /lib64 a real directory and put just the interpreter in it. > All other libraries go to /lib. > > 3. Make /lib64 a real directory and put the interpreter in it. > Compile some things like gcc and libc6 as multilib/biarch and put the > 32bit libraries in /lib and the 64bit libraries in /lib64. All > other libraries go to /lib. > > I do not yet know which of those options would be the best. Maybe we > should stay with Option 1. which is implemented in 'pure64' now for the > moment. I think it will be possible to change things later without > breaking too many things. Option 1 is what we've got now, Option 2 doesn't really have any benefit to it that I can see, so I don't see any good reason to move to that. Option 3 wouldn't be for pure64 and for multiarch there's a better solution already. Stephen
Attachment:
signature.asc
Description: Digital signature