[arch-ports] 32bit support
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#id271960 Also I would like to mention that vitorlima has joined the project and has already made great contributions! - syamajala
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#id271960 Also I would like to mention that vitorlima has joined the project and has already made great contributions!
- syamajala _______________________________________________ arch-ports mailing list arch-ports@archlinux.org http://www.archlinux.org/mailman/listinfo/arch-ports
On Mon, Sep 19, 2005 at 05:03:48PM -0400, seshu yamajala wrote:
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.
I think that's probably a good idea to leave out those things if you actually don't plan on booting. Would there ever be a time that an arch64 user would want to boot into a full 32 bit OS? I don't know how you were going to let users install the 32 bit compat packages. Maybe if you used a group and then depended on the group (I can't remember if you're allowed to do that), then you could have a 32bit-compat-base and 32bit-full, which installed a compatibility 32 bit chroot or a fully bootable 32 bit system respectively. Jason -- If you understand, things are just as they are. If you do not understand, things are just as they are.
participants (2)
-
Jason Chu
-
seshu yamajala