On Tuesday May 25 2010 07:18:33 pm robert baker wrote: > Below you will find my suggestions for the scope of the HLFS book. > > What we want to provide. > - A base platform and build environment > - A platform for building hardened servers, routers, and firewalls > > > Work needed to reach a release candidate > > - various package version bumps > - frandom update > - glibc-sanitize-env > - grub2 > - fortify source by default > - test suite/sanity checks > - x86_64 and i?86 build completion > - multi-lib or pure64 or both > - if pure64 is included patches or additional seds are needed > - ssh daemon for bootable_temporary > - libcap-ng (requires python) > - completed book text > > In my oppinion HLFS-1.0 should be limited in scope to just the basic > toolchain. Very few packages should be added beyond the scope of LFS. > Those packages include libcap, (if we use libcap-ng we need Python > too.) paxctl, and an ssh daemon for the bootable temporary tools. All > other work should be focused on preparing the build environment and > base install. > > HLFS-2.0 should be a more aggressive target. I would like to see the > book include documentation on grsec's RBAC system. I would also like > to see a full audit of posix capabilities on the binaries included in > the base system. Some documentation on posix capabilities would also > be a nice addition. Any additional packages that we agree should be in > the book should be added for the 2.0 version. > > Any thoughts/comments/additions are welcome.
The reboot is needed for the new capabilities module (which is now built in non-optional in recent kernels), and the extended attribute options for the filesystem. Almost all distributions enable all these kernel modules, so rebooting chapter 6 is probably not necessary for most of us. This could be added to host system dependencies, instead of adding a reboot to chapter 6. A couple LFS packages (Sed and Coreutils, maybe others) will link to libcap2/libattr/libacl. So this can be used as-is. The Coreutils test suite took me some work to get all the dependencies for the tests, but this might be better with version 8.5. I think it depends on acl/attr mount options. An old idea was to take the LFS stable book (LFS-6.6 for example) and modify it. I think this would simplify a lot of things. HLFS would be patches on the LFS book and packages. The patch for the book eventually gets larger and larger, but this can be worried about when it becomes a problem. With this system, the HLFS stable book would release shortly after each LFS stable release. New HLFS releases don't necessarily mean new features are added, it could just be maintenance. New stuff is added when it works. Exactly the same thing could be done with BLFS (if or when they do not accept HLFS changes to the BLFS book). robert
pgpV6R1mvuc01.pgp
Description: PGP signature
-- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
