I am thinking about closing the subject ticket as WONTFIX. There are a few reasons for this:
1. The reason for multilib in the first place is to handle packages that are pre-compiled for a 32-bit only environment. It only is needed on a 64-bit system. 2. There are very few packages that actually need it. Almost all of them proprietary. Open source packages can be fixed to build in the native 'pure-64' environment. 3. Even proprietary packages are making 64-bit versions available (e.g. Nvidia, VMWare, and Adobe). 4. There are conflicting ways to implement multilib. For example, is the paradigm /usr/lib and /usr/lib64 (like RedHat, Novell, and derivitives)? Or is it /usr/lib and /usr/lib32 (like Debian and derivitives)? 5. Building multilib consists of building packages multiple times making the instructions int the book quite a bit more verbose and complicated. We already have a lot of problems with users just trying to build a single version of the packages. Adding this complication goes against the philosophy of making the book relatively straight line. Looking at a CentOS distribution, they have 1707 entries in /usr/lib64 and 1281 in /usr/lib. That doesn't count libraries in subdirectories. That's a lot of work for a few binary only packages. For comparison, I have 1439 libraries in /usr/lib. 6. If an advanced user wants to build a multilib system, they can use cross-lfs or diy-linux. We already refer to cross-lfs in Section iii LFS Target Architectures. For the costs in manpower and complexity, I see very little value added in this ticket. The only thing then needed is to update the 5th paragraph in Section iii. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
