Re: A More Radical Multi-Arch Counter-Proposal
Bill Allombert <firstname.lastname@example.org> writes:
> On Sun, Jan 18, 2004 at 10:26:45AM +0100, Goswin von Brederlow wrote:
> > Bill Allombert <email@example.com> writes:
> > > Do you imply that some design decisions will make the above arrangement
> > > impossible ? Or that a native amd64 port is out of the question ?
> > Every other linux is already using /lib, /lib32, /lib64 to make
> > multiarch binaries work. That means upstream authors get patches for
> > that way. Starting something new means Debian will stand alone.
> No Linux distribution provide multiarch today. But you do not answer my
SuSe and RH amd64 allow multiarch. Afaik their packaging system does
not encourageit, but it works.
> question: Will the multiarch allow me to install both chroot with only
> one arch in each as mentionned above ?
i386 keeps as it is, so thats no problem. For amd64 if you remove
i386-i686 from the compatible archs in the conffile for dpkg you have
a amd64 single arch system. Provided enough debs are available as 64
bit, which isn't yet the case.
The goal is to support i386, amd64 and i386+amd64 systems.
> > A chroot is also a far worse choice to have multiarch support then the
> > existing and perfectly working lib64. There is just no reason to give
> > that up.
> Why ? I find a chroot way cleaner than hard-coding a bit-length in a
> path. Are we going to have lib128 and lib256 ?
You are a few years to late for the lib64 decission and I don't realy
care what the libdir for amd64 is set to, set it to
/foo/bar/baz/lib if you like. Changes nothing.
The way lib64 is done in debian-amd64 is by asking dpkg what the right
libdir and libprefix should be for this arch. If amd builds a
i386/amd64/amd128 cpu a lib128 can be added in a second. lib64 can be
changed to lib/amd64/ in a second. Doesn't affect the problem or
> > Think about what it means for mips, sparc, s390 and powerpc.
> As far as I know, chroot(2) exist on those platforms.
But they neither have nor want a full 64 bit system. Why should they
need to port, use and maintain a 64 bit make, automake, autoconf, gcc,
binutils and all essential/build-essential debs all of which are
slower just for a 64bit postgresql?