ok, so i tried it out. It works! I am gonna write a bash script that will setup a 32bit chroot. Mr. Green has written a barebones pkgbuild for dchroot too. I haven't tried dchroot yet, but I will soon. Also, i'm trying to figure out which packages can be cut from the chroot env, because i think it would be a waste of space and bandwidth to download all the packages needed for a base install if the user isn't going to actually boot into the system. I was thinking about getting rid of things like reiserfsprogs, initscripts, wireless_tools, that kind of stuff. Would this be a good idea? Or should I just leave them.
On Sep 18, 2005, at 9:08 PM, seshu yamajala wrote:
I have found a much better solution for the 32bit backwards compatibility issue. After looking at how debian does things, i have found that for 32bit support they setup a chroot. I thought about this, and it seems like an excellent idea. It will save a lot of time, and it addresses the problem of installing 2 versions of the same package. dchroot could be used to make the chroot almost transparent to the user. The existing 32bit arch packages could be used as well. Since i have not started working the multilib support, this will probably be implemented instead. For more info on the chroot method look here:
https://alioth.debian.org/docman/view.php/30192/21/debian-amd64-howto.html#id271960Also I would like to mention that vitorlima has joined the project and has already made great contributions!
- syamajala
_______________________________________________
arch-ports mailing list