On Thu, 2004-12-09 at 23:07 +0100, Goswin von Brederlow wrote: > Ian Murdock <[EMAIL PROTECTED]> writes: > > 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. > > PS: The above lib dirs are the best and only practical solution we > have for multiarch.
I understand the LSB is beginning to think about the multiarch issue, and I suspect Debian is far ahead of others in terms of practical experience with this problem; so, it's not only reasonable to expect the LSB will help resolve this potential nightmare, but also that Debian could be at the forefront of helping resolve it. -- Ian Murdock 317-578-8882 (office) http://www.progeny.com/ http://ianmurdock.com/ "All men dream: but not equally. Those who dream by night in the dusty recesses of their minds wake in the day to find that it was vanity: but the dreamers of the day are dangerous men, for they may act their dreams with open eyes, to make it possible." -T.E. Lawrence
