Re: Upcoming Debian multiarch support (amd64, sparc64, s390x, mips64) [affects sarge slightly]
firstname.lastname@example.org (Claus Färber) writes:
> Goswin von Brederlow <email@example.com> schrieb/wrote:
> > firstname.lastname@example.org (Claus Färber) writes:
> >> The method of putting libraries into /lib/ and /lib64/ does not work
> >> if you want to have i386 and ppc, for example, on the same system.
> > The decision to put libraries inot /lib and /lib64 has been made quite
> > some time ago and works fine.
> It does not work with multiple architectures where "multiple" does not
> mean "two, which differ in word size".
I think mips uses /lib, /lib32 or /libn32 and /lib64. Thats 3 abis
with 2 bitdepth for 2 archs.
> If all library packages have to be changed anyway (to allow them to
> install into /lib64), we can as well change them to make the more
> general case of installing any two different architectures work, too.
> The small change to ldconfig is hardly more work.
The problem with changing that is getting the rest of the world to
follow. The lib64 changes can be send upstream or already have been
send upstream by SuSe and RH developers. A lot of work can be shared
between distributions that way.
Changing the commonly accepted position of libs and binaries means a
change to every package in debian, not just libs (which is what I try
to limit changes too) even for all the released architectures. Such a
huge change can't be done in less than 2 releases and that means 4
years. I don't want to wait that long.
With the /lib64/ changes it is trivial to change the actual path for
the libs, since dpkg-libinfo (to be merged into dpkg-architecture)
provides the path. If the path is changed a simple recompile of all
packages will make the change.
> > I would say thats pretty much unchangeable now without a realy good
> > reason. Everyone objecting to /lib64 is a few years to late.
> Please note that my proposal also affects /lib, not only /lib64.