DJ Lucas wrote:
> On 09/02/2011 05:27 PM, Jeremy Huntwork wrote:
>> Dan Nicholson also did much work to get them ready. This has all been
>> discussed and agreed upon by the community from years ago. It's crazy
>> that they should still be rejected and not part of the major reason
>> for releasing a 7.0.
>
> Don't forget that Alexander and Nathan jointly wrote the original
> initd_functions script back in 2006. Mine, Dan, and Jeremy's work were
> an extension of that single script (a complete rewrite of the original
> package and tools to take advantage of Nathan and Alexander's work)
> which was started several years ago. Bruce's work, while also a complete
> rewrite, is a further continuation of that still. Now that I've actually
> put a little time into reviewing Bruce's work, and although this is not
> a thorough review, I have five major objections to considering them
> release ready (one of which is unfortunately irreparable without major
> disruption to the release cycle), and two additional minor objections
> that can be easily fixed. Most of these are due to the immaturity and
> lack of community interest/time in the rewrite. I'll present them in a
> 1:1 comparison with the LSB scripts which I'd consider fairly mature in
> its fifth year of development (with the exception of the new networking
> scripts).
>
> First, as evidenced by the lack of participation in dev, the new scripts
> really have not been tested enough to be considered for release. This is
> a major change and should be committed immediately after a release, or
> at latest around the middle of the release cycle, not a month before
> release. This is why the discussion in early May, and all the time spent
> in May on the LSB variant while interest was high. Since the new scripts
> are already in there and LFS is preparing for release, my suggestion is
> to fix what can be easily fixed before release and just roll with it.
> Regardless of maturity, since they've already appeared in the RC, a
> roll-back would likely be sloppy and be yet another dismissal of
> expended effort.
I agree with this comment. One mitigating thing that we can do is make
the RC cycle an extended one. We don't have to hurry the final release.
> Second, the lfs-functions script does not leverage the LSB defined
> functions either by wrapping the LSB functions in LFS specific functions
> or by direct use. The benefit of using the LSB defined functions is that
> output consistency is guaranteed no matter the source of the script (if
> it is written to spec, which admittedly, hasn't always been the case
> with many of the scripts found in the wild). The benefit here, if it is
> not obvious, is that compliant vendor provided scripts need not be
> rewritten to work on {B}LFS or any other consumers of the base LFS for
> various appliances such as IPCop, or IPFire, or any other distribution
> such as LightCube that choose to use the LSB scripts. One of the core
> goals of the bootscripts project, back when it was a separate project,
> was to be completely distribution independent. This goal should not be
> lost to down stream consumers. Additionally, the lfs-functions should
> use the LSB defined return values to provide more intelligent output
> besides the basic OK, WARN, and FAIL messages (an added benefit of using
> wrappers around the LSB functions). Strings such as 'invalid argument',
> 'file not found', or 'excessive arguments' aide in troubleshooting
> problems with a new script.
I don't see any problems with making that happen.
> Third, the work that went into the networking scripts and the long
> discussion threads about them was almost completely omitted in the new
> scripts. The relocation was the only discussed item that was kept
> AFAICS. At present, with Jeremy's additions, the network scripts
> contained in the LSB bootscripts, while still immature, handle almost
> every possible expectation of users coming from other distributions,
> with ease. Yes, that functionality comes at the price of mild difficulty
> in reading, but the coding style IMO is far more readable than any other
> examples I've found in the wild, while maintaining or exceeding the
> level of functionality for competing implementations, and yet still
> providing ease of extension for various other services (and only minor
> changes to the services contained in BLFS currently).
One of my main goals was to try to make the scripts understandable.
After all one of the book's main goals is education.
> Fourth, now that ifup and ifdown are installed in a system location
> (/sbin), they need to have a -h|--help switch with help text (or
> man/info pages added). At least intelligent error handling was retained
> from the previous networking discussion. Help text and argument
> processing absolutely *must* be added before you can possibly consider
> those scripts a final product if you intend to put them in a system
> location.
Yes, I meant to do the man pages. Good observation about the --help
switch. I'll add those.
> Fifth, as far as I've seen, no effort has been put into writing
> compatible scripts for BLFS yet, only the dhcp service script has been
> discussed. The LSB scripts already have about 60% coverage (most of
> those are already in the contrib directory in the blfs-bootscripts pacakge).
After the LFS release, I plan on putting a lot of effort into BLFS. I'd
like to see a real release by the end of the year. I planned on
updating the bootscripts then. I did leave the sysconfig/rc file in the
bootscripts tarball for BLFS compatibility although it is never
referenced in the new LFS scripts. I is probably not enough though.
> The sixth (minor) point, is that /run is mounted at mountvirtfs instead
> of in rc directly. There were a couple of reasons for having the tempfs
> mounted prior to running any other scripts, the major one being that the
> temp directory is available for early boot logging (sysinit) and other
> early accounting tasks such as storing an interactive boot flag when
> switching from sysinit to the default runlevel.
It could be put into init.d/rc, but it is instead the very first thing
in the first bootscript (and before any messages). Since mountvirtfs is
only ever run from rcsysinit.d and only has a 'start' function, moving
it would functionally be no different from having it in init.d/rc.
> The seventh (minor) point, is that boot logging still runs after boot.
> In my personal opinion, it should only run if PREVLEVEL is N or S,
> though I had actually compromised on the exception of RUNLEVEL 0 or 6 by
> request (well prior to the LSB bootscripts) due to the possibility of
> changing run level on remote (or headless) systems. This seems very
> unlikely in hind sight, except for maybe the test runlevel 4, but even
> that output would likely be on screen unless you are replacing your
> method of remote access.
I tried to model the boot logging after dmesg. That is, all things
relative to the bootscripts should be logged. In this case, more info
is better than less. Second, the logging is done to /run (a tmpfs) so
they are not available from a prior boot unless they are copied
explicitly to to another directory.
> More to come (along with suggested fixes) when I actually put them into
> use over the next couple of days.
That would be very welcome.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
