Some packages I'd like to see added
Kevin P. Fleming
kpfleming at linuxfromscratch.org
Fri Dec 31 09:40:38 PST 2004
Randy McMurchy wrote:
> Perhaps you have a point Jim. But because I'm not a fan of using
> the .d directories when a single file works just as well, I didn't
> want to do it. Not counting the work it would take to go through
> the book and replace all the entries of adding a section to xinetd.conf
> and replacing them with files in /etc/xinetd.d.
I'll jump in here in support of Jim's suggestion, for what it's worth.
The way I see it, directory based configuration is actually a _big_
improvement for something like the BLFS book, because it makes every
package independent. Each package's instructions can just say "create
this file here with these contents", without any effort to tell the user
about adding them to an existing file, checking for conflicts, etc. When
the BLFS book is turned into any kind of automated system (ALFS,
scripts, whatever), it helps even more.
Personally, I used directory-based configuration wherever I can; it's
why I lobbied so hard for directory-based conf in
/etc/sysconfig/network-scripts in the LFS bootscripts tarball, and the
result has been very good. We now have service scripts to do many more
things that we had before, and turning them on and off is very simple,
and doesn't affect any other service scripts for that interface.
While the potential benefits for xinetd are lower, they are still there,
and there is something to be said for consistency as Jim pointed out.
> I don't care either way, mind you, I just felt my time was better
> utilized in improving the book in other ways, than to spend a
> bunch of time redoing what already works.
I won't dispute that; I would only suggest that instead of wording it
this way, you might choose to say:
I don't have time to convert all the existing packages in the book that
have xinetd-related instructions, but Jim, if you're willing to create a
patch to do that, we'll consider converting the book over en masse.
Then the other editors can look at what's actually involved and whether
it would cause an ongoing maintenance burden. Is that reasonable?
More information about the blfs-dev