Ticket #2491 Add multi-lib capabilities
bruce.dubbs at gmail.com
Sun Jan 31 14:01:06 PST 2010
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
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.
More information about the lfs-dev