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.
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.
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).
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.
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).
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.
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.
More to come (along with suggested fixes) when I actually put them into
use over the next couple of days.
-- DJ Lucas
--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
