Re: I need explanation on the design of debian-amd64.
- To: email@example.com
- Subject: Re: I need explanation on the design of debian-amd64.
- From: Goswin von Brederlow <firstname.lastname@example.org>
- Date: Wed, 01 Dec 2004 11:15:42 +0100
- Message-id: <email@example.com>
- In-reply-to: <20041130160734.GD14218@dementia.proulx.com> (Bob Proulx's message of "Tue, 30 Nov 2004 09:07:34 -0700")
- References: <firstname.lastname@example.org> <email@example.com> <20041129080937.GA23072@dementia.proulx.com> <firstname.lastname@example.org> <20041130051638.GB9200@dementia.proulx.com> <email@example.com> <20041130160734.GD14218@dementia.proulx.com>
firstname.lastname@example.org (Bob Proulx) writes:
> Goswin von Brederlow wrote:
> Another alternative I am working through the details for right now is
> the exact reverse. A 32-bit base system with a 64-bit /emul layer.
> Then the small number of programs that need the larger memory space
> run transparently. But in general the system is simpler to administer
> for the casual user in my lab.
You actualy don't need emul there. Link the lib64 dirs into an empty
chroot, install amd64-libs, dpkg-divert the files (so it doesn't get
installed accidentally later and messes with the chroot), install
>> I see the point of having a chroot to install lib packages and then
>> install binaries (with --force-arch for example) outside the charoot
>> or something. But in general it doesn't always work. Not something for
>> the faint of heart.
> I never use --force-arch and would advise against doing that. (shudder)
> I agree that having a multi-root system is more complicated than
> having a single-root system. I agree that some people will be
> confused by it beyond being able to administer one well. So I also
> would not recommend it for everyone. But for most system
> administrators it is a useful tool in the toolbox. One that I use to
> good effect daily.
Sarge needs to be released so we can start applying multiarch patches.
After that it is just a matter of "apt-get install libfoo:i386" or
even simpler "apt-get install open-office.org" will do the right
>  CAD vendors usually "install" their software in a shared
> filesystem location. Their installation processes are usually
> terrible shell scripts written without any real thought. Someone at
> the vendor wrote the script to just slams files out into a directory
> somewhere and they expect you to be able to run them on your machine.
> We have 30+ different applications all with completely different
> processes to manage them. No thought is given to system dependencies
> such as required libraries or programs. Well, actually they just say
> all of the world is a VAX, er I mean all of the world is MS-Windows,
> er I mean all of the world is RHEL3.0. You get the idea. People like
> myself who administer these environments just deal with it.
A lot of 3rd party software has most libs statically linked in. A lot
of the time you just need the core libs (glibc, libstdc++). But it all