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.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
