Find my comments in-line with yours. On Wed, May 26, 2010 at 2:14 PM, Dean Takemori <de...@hawaii.rr.com> wrote: > >> Date: Tue, 25 May 2010 18:18:33 -0500 >> From: robert baker <robertmba...@gmail.com> >> Subject: HLFS project scope. >> To: Hardened LFS Development List <hlfs-dev@linuxfromscratch.org> >> Message-ID: >> <aanlktinmbwmfsuk5ojhd-6pejcqv9n6zdlmzq9pjr...@mail.gmail.com> >> Content-Type: text/plain; charset=ISO-8859-1 >> >> Below you will find my suggestions for the scope of the HLFS book. >> >> What we want to provide. >> - A base platform and build environment > > I'm assuming you mean a replacement for the LFS-Live .iso > specifically meant for HLFS builds?
No. I mean the HLFS system it's self. That statement was more or less the goal of the HLFS-1.0 release in a nut shell. >> Work needed to reach a release candidate > > - I think the biggest TODO: is to establish the "official" > package list (with major-version number) and the build order The official package list should closely mirror current stable LFS where possible. >> - various package version bumps > > >From experience, this is a constantly moving target, a > freeze on major version numbers for certain targets would > have to be a early milestone. I agree this has been an issue in the past. It would make me cringe to see suggestions for package version bumps in most cases as well. However there is very little needed to bump package versions to the LFS level, and most of the work is already done. There are just a couple of changes to be made in the temporary tools and the rest will follow quickly. I will be making updates to SVN shortly with the work I have been doing so you all can get a better idea of just how close we are. For the record I am only suggesting bumps to reach the package level of the current stable LFS. >> - grub2 > > A little bit tricky. A full build-from-scratch requires > building freetype for the font. Despite having done work > to do it for my own builds, I would vote to save this for > (say) v1.2 since there's plenty of work to do already. > That has not been my experience. I have built grub-1.97.2 with little effort and no additional packages. I even managed to build it for booting temporary without difficulty. As an aside, I have been going back over the need for a bootable temporary system. All things considered capabilities can be set after the reboot into the final system and that was the major reason to make temp bootable. >> - fortify source by default >> - test suite/sanity checks > > Probably the third biggest TODO: determining which tests return > false negatives, which ones are critical etc. There are very few test failures when you run the tests using the vanilla specs w/ -fno-stack-protector -fno-PIE I have some more work to do in this area but suffice it to say the failures are minimal, and documenting them when we have a final test procedure will be trivial. >> - x86_64 and i?86 build completion >> - multi-lib or pure64 or both >> - if pure64 is included patches or additional seds are needed > > How important is a 64-bit build to v1.0? Might it be better > to focus on a single target (x86) and then work on the 64 > bit version for (say) v1.2? > In my opinion it is arguable either way. If we arrive at a general consensus that we should focus on one architecture then we can push 64bit to version 2.0. I will say that if we build a multilib 64bit system that there isn't a whole lot of additional effort involved. Pure64 isn't a huge effort, but it is more work than multilib. >> - libcap-ng (requires python) > > I would vote no on this; Is there a compelling reason to use > it rather than libcap for v1.0? > The most compelling reason for it is that it is an actively maintained project. Second to that it is easier to use than the traditional libcap because it has a more comprehensive toolset. > -dean takemori > -- > http://linuxfromscratch.org/mailman/listinfo/hlfs-dev > FAQ: http://www.linuxfromscratch.org/faq/ > Unsubscribe: See the above information page > -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
