Ian Murdock <[EMAIL PROTECTED]> writes:
> On Thu, 2004-12-09 at 09:07 +0100, Scott James Remnant wrote:
>> On Wed, 2004-12-08 at 14:59 -0800, Bruce Perens wrote:
>>
>> > The main technical effect that I see would be that the names of some
>> > dynamic libraries would change. And compatibility with the old names
>> > could be maintained indefinitely if necessary.
>> >
>> ?!??!?!?!?!?!?!"PO!(*"!$*_(!$*"($*!("*$_*!"*$("
>>
>> That is all.
>
> Well, that's certainly constructive.
>
> Can someone provide an example of where the name of a dynamic
> library itself (i.e., the one in the file system, after the
> package is unpacked) would change? I'd be surprised if this was
> a big issue. The LSB/FHS should take care of file system level
> incompatibilities already (though Debian may put some things in
> /lib that RPM-based distros put in /usr/lib due to more strict policy
> about such things), so I'd think the main issue wouldn't so much be
> about the names of the dynamic libraries themselves, but the names of
> the packages they come in (acl vs. libacl1, as per my last message).
When multiarch hits all (core) libs will move around
drastically:
/lib/* -> /lib/`gcc -dumpmachine`/
/usr/lib/* -> /usr/lib/`gcc -dumpmachine`/
/usr/X11R6/lib/* -> /usr/X11R6/lib/`gcc -dumpmachine`/
If you aim at having the same path to libs (which only broken rpath
needs) then this will be your nightmare.
MfG
Goswin
PS: The above lib dirs are the best and only practical solution we
have for multiarch.
