A few notes on testing
jwrober at linuxfromscratch.org
Mon Jul 12 07:21:17 PDT 2004
Jeroen Coumans wrote:
> James Robertson said the following on 12-07-2004 04:19:
>> 1.) CH5 - at the end, before the strip command - would it be ok, to
>> add a list of "optional" packages to the tools set? I was thinking of
>> vim and less for sure. We would not provide instructions of any kind
>> (pointer to ch6), just a "hey, we don't need these directly, but they
>> may come in handy in ch6" page. I know, we don't want to provide too
>> much option in the book - one path only - but this small change is
>> more for testers and such that could use the reminder of other things
>> that could be useful.
> This would be OK in a test branch, but not in the stable book. The
> target audience of the stable book is not testers, but
> intermediate/advanced Linux users who want to learn more about Linux.
That makes sense. No need to confuse matters in stable. That would
mean yet, one more thing to worry about when going to stable, so maybe
not a good idea after all. I'll just personally keep notes on what
extras I want in my toolkit. I just thought others might find it useful.
>> 2.) End of CH6, before strip - mention TCL, Expect and DejaGnu before
>> the strip command. That way, if one decides to go with those, they
>> will have them already before the strip and won't have to go back and
>> do it again.
> Wouldn't it make more sense to specify that in the respective TCL,
> Expect and DejaGnu pages themselves?
Well, there is this note box on :
That could easily be moved to the page before at:
before we explain how to do the strip. That is all I was really after.
>> 4.) The (now removed redirected) link to the kernel build howto
>> mentions two packages (lspci from pciutils) and mkinitrd. Would it be
>> a good idea to put these in LFS as base packages? My rationale would
>> be for kernel building dependency.
> Do we want optional dependencies in the book? We've already discussed
> this to death with hotplug & udev. The final rationale for putting those
> in was that they are useful for a very large group of our audience, and
> are the most technically correct way to deal with hardware & devices.
> Just being an optional dependency was not enough to include them, so
> neither would it be for pciutils and mkinitrd (which are both in BLFS,
> so we can always refer to those pages if necessary).
I was making a note that we used to direct the reader to a page (howto)
on building the kernel that used two tools that we don't have installed
as a base LFS box. I was not advocating any way. We have removed the
link in testing (probably was never in unstable, not sure though), so it
is kinda moot. If we do put the link back, we might want to worry about
it. It could simply be a link over to the BLFS pages for those packages
stating the obvious (If you need pciutils or mkinitrd read these pages...).
Also, along the lines of building the kernel, I would like to see some
more info in the book on modular vs non-modular kernels. Goes to
education. I think it would be a good idea to lean the first time LFSer
to a non-modular layout. Simpler IMO. I have been doing LFS for over
1.5 years now off and on and still have issues with modules. :-\
The howto we used to link to provides the basic steps and only a little
explanation on the huge amount of features and choices to be made in the
kernel build process. Is there more we should/can/want to provide?
More information about the lfs-dev