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 mailing list