Re: I need explanation on the design of debian-amd64.
[EMAIL PROTECTED] (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 chroot. 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 thing. Bob [1] 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 depends. MfG Goswin
Re: I need explanation on the design of debian-amd64.
[EMAIL PROTECTED] (Bob Proulx) writes: Goswin von Brederlow wrote: [EMAIL PROTECTED] (Bob Proulx) writes: But if 'dchroot' is configured with the ia32-linux chroot then you can just say dchroot apt-get install foobar to install a 32bit package. dchroot will only work if you have a chroot. Yes. In particular it won't work if you are using ia32-libs. But personally I think ia32-libs is the wrong direction to go. I believe the chroot method to be the better alternative. And if you do why bother with /emul? Having /emul allows me to transparently run binaries outside of the chroot. All of the world is not openoffice.org-bin or mozilla-firefox packages. The chroot works great for those 32-bit applications. But having /emul allows me to run /net/ia32fileserver/cadroot/bin binaries on my 64-bit system completely transparently. Having the chroot allows me to install and upgrade 32-bit binaries easily. Having a 64-bit base system allows me to install and upgrade 64-bit binaries trivially. The best of all worlds. In summary, I am using the chroot to manage /emul. Bob The problem is that many programs have data files in /usr/share or /usr/lib/package or even config in /etc/. All those files will be inside the chroot instead of outside when you run the program outside. So the number of programs you can run outside is somewhat limited. 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. MfG Goswin
Re: I need explanation on the design of debian-amd64.
Goswin von Brederlow wrote: The problem is that many programs have data files in /usr/share or /usr/lib/package or even config in /etc/. All those files will be inside the chroot ... Yes. ... instead of outside when you run the program outside. Any program that needs to be *installed* will need to run from the chroot. Agreed. But any program that can simply be run can be run either place. Many (most?) random programs can be run outside the chroot. It really depends upon what it is you are trying to do. So the number of programs you can run outside is somewhat limited. I think this is just a difference in world view between your environment and mine. In mine only those two binary packages I mentioned really need to run in the chroot. A short list. Just openoffice and firefox. In the chroot. Done. However outside the chroot I have hundreds of CAD/EDA programs that are legacy 32-bit applications. They run from an NFS fileserver. They don't actually ever get installed on the local machine[1]. But the binaries are run just the same. That does not even mention the random programs that users would use from their $HOME directory or copy to /usr/local/bin. The list is open ended. The choice would be a 32-bit OS to be able to run those programs. Except that amd64 can run both 32-bit and 64-bit applications transparently. That means I can also benefit from the large memory model available in 64-bit for the smaller number of 64-bit CAD/EDA programs that need it. A good result. 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. 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. Bob [1] 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. signature.asc Description: Digital signature
Re: I need explanation on the design of debian-amd64.
Goswin von Brederlow wrote: You can use /emul/ia32-linux/lib (as the ia32-libs, ia32-libs-dev and ia32-libs-openoffice.org packages already do). The drawback of this method is that you can't just apt-get install foobar to install a 32bit package. But if 'dchroot' is configured with the ia32-linux chroot then you can just say dchroot apt-get install foobar to install a 32bit package. Bob signature.asc Description: Digital signature
Re: I need explanation on the design of debian-amd64.
[EMAIL PROTECTED] (Bob Proulx) writes: Goswin von Brederlow wrote: You can use /emul/ia32-linux/lib (as the ia32-libs, ia32-libs-dev and ia32-libs-openoffice.org packages already do). The drawback of this method is that you can't just apt-get install foobar to install a 32bit package. But if 'dchroot' is configured with the ia32-linux chroot then you can just say dchroot apt-get install foobar to install a 32bit package. Bob dchroot will only work if you have a chroot. And if you do why bother with /emul? MfG Goswin
Re: I need explanation on the design of debian-amd64.
Goswin von Brederlow wrote: [EMAIL PROTECTED] (Bob Proulx) writes: But if 'dchroot' is configured with the ia32-linux chroot then you can just say dchroot apt-get install foobar to install a 32bit package. dchroot will only work if you have a chroot. Yes. In particular it won't work if you are using ia32-libs. But personally I think ia32-libs is the wrong direction to go. I believe the chroot method to be the better alternative. And if you do why bother with /emul? Having /emul allows me to transparently run binaries outside of the chroot. All of the world is not openoffice.org-bin or mozilla-firefox packages. The chroot works great for those 32-bit applications. But having /emul allows me to run /net/ia32fileserver/cadroot/bin binaries on my 64-bit system completely transparently. Having the chroot allows me to install and upgrade 32-bit binaries easily. Having a 64-bit base system allows me to install and upgrade 64-bit binaries trivially. The best of all worlds. In summary, I am using the chroot to manage /emul. Bob signature.asc Description: Digital signature
Re: I need explanation on the design of debian-amd64.
[EMAIL PROTECTED] writes: Hi! I would like to ask this: ... Is there any way in wich I can have both kind of libraries in my system?, I mean, something like this: lib : 32bits libraries. lib64: 64bits libraries. and have almost all of my system running 64bits binaries (except by: openoffice, doom3, mplayer with w32 codecs, you name it). Pure64 is primarily made only for 64 bit. Any 32bit support comes as an afterthought. Because of various reasons lib64 is a link to lib so your idea won't work. But there is no problem with your idea, just with the directory names. You can use /emul/ia32-linux/lib (as the ia32-libs, ia32-libs-dev and ia32-libs-openoffice.org packages already do). The drawback of this method is that you can't just apt-get install foobar to install a 32bit package. This way, I could have a true hybrid system, with some 32bits binaries and some 64bits binaries sharing the same filesystem and hardware devices, without the need of duplicated binaries. Please, somebody correct me if I'm geting things wrong. Thanks in advance for your help, and keep up the good work! Ildefonso. MfG Goswin
Re: I need explanation on the design of debian-amd64.
[EMAIL PROTECTED] wrote: I only have a 10Gb HD (for the moment, I'm saving to get another), so I don't find it really attractive to install the full 64bits system, and then install lots of 32bits libraries (and maybe other binaries) in a chroot jail just to run, say, doom3, or openoffice.org. So, my question is: The chroot basically consumes whatever it takes to run the binary. There is some unused overhead. In only a 10GB filesystem you will need to be more careful than most. But a basic system consumed around 100MB and grows from there. I would guess 500MB for a mostly usable system. Is there any way in wich I can have both kind of libraries in my system?, I mean, something like this: lib : 32bits libraries. lib64: 64bits libraries. That is the old biarch model of supporting two architectures. But it is truly horrid. It has many problems. I suggest you look at the multiarch proposal. It is a much better method of handling multiple architectures. http://www.linuxbase.org/~taggart/multiarch.html In any case, right now the typical better model is to use a chroot install of the non-native binaries and either put them in /emul/ia32-linux or make that a symlink to the actual location. The Debian amd64 howto documents that process quite well. Hopefully eventually the proposed multiarch will replace all of this. and have almost all of my system running 64bits binaries (except by: openoffice, doom3, mplayer with w32 codecs, you name it). I run my 64-bit system just that way. Bob signature.asc Description: Digital signature
