[RFC] On LFS' Package Selection Policy

Matthew Burgess matthew at linuxfromscratch.org
Fri Aug 5 05:29:53 PDT 2005


Hi,

During the recent thread on whether or not Cracklib should be introduced 
to LFS, the lack of an official policy on what criteria a package has to 
meet in order to be included in the book was highlighted.  So, to 
correct that, I'm going to get the ball rolling (after first donning my 
flameproof suit!) with the following list.  This is by no means supposed 
to be comprehensive or reflect in any way the packages included in the 
current book.  It's simply a list of what I think of as sensible guidelines:

1) Are the utilities and/or interfaces the package provides mandated by 
any of the following standards?
    * Filesystem Hierarchy Standard (FHS-2.3)
    * Linux Standard Base (LSB-3.0)
    * POSIX Single Unix System V3 (IEEE Std 1003.1 or ISO/IEC 9945:2003)

2) Are the utilities and/or interfaces the package provides listed as 
optional in any of the above standards, and are generally considered so 
useful that by omitting them, a base system would be lacking significant 
functionality?

3) Are the utilities and/or interfaces the package provides mandatory 
build and/or runtime dependencies of another package that is accepted 
under criteria 1-3?

4) Are the utilities and/or interfaces the package provides an optional 
build and/or runtime dependency of another package that is accepted 
under criteria 1-4, and that by omitting them, a base system would be 
lacking significant functionality?

5) Are the utilities and/or interfaces the package provides so generally 
useful in a base system that by omitting them it would be lacking 
significant functionality?

6) Where multiple packages are available that offer the required 
functionality, each must be assessed relative to each other regarding 
(in no particular order):
   i) Stability/maturity
   ii) Level  of current maintenance activity
   iii) Upstream communication channels (e.g. support/dev mailing lists, 
bug reporting interfaces, SCM availability)
   iv) Ease of compilation/configuration
   v) Features.

Obviously what is considered 'significant functionality'/'useful' is 
open to personal opinion, and point 5 is just there to catch things 
(e.g. sysklogd) that aren't mentioned in any of the standards or are 
build/runtime dependencies of any other package.  Sysklogd might not be 
the best example here - I have no idea what would happen if you removed 
syslogd and/or klogd!

Thoughts, comments, suggestions?

Regards,

Matt.



More information about the lfs-dev mailing list