[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Get rid of the lib64 dir?

* 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.


Attachment: signature.asc
Description: Digital signature

Reply to: