Ken Moffat wrote:
On Mon, Feb 08, 2016 at 04:17:06PM -0600, Bruce Dubbs wrote:
Ken Moffat wrote:
My preference is recommended, if possible. But agree with Ken's decision
if he still wishes to promote to required
My rationale is that Recommended either means
(i.) The package can build without this, and without extra configure
switches, but the recommended package provides useful extra
functionality (is that a word ?)
or
(ii.) The package can be built without this, but you need to supply
extra configure switches.
This package, as shipped, matches neither option. I am reluctant to
include a patch in the book just so that people can detune what
upstream shipped.
My definition of recommended is that the package provides extra
functionality for the package that you probably want. The instructions
provided also assume that all recommended packages are installed. If you
don't want to install a recommended dependency, then there may be other
things that you need to do to build the package. Those things may include,
but are not limited to, a modification of options for configure.
-- Bruce
In this case, I am sure that the additional package provides extra
functionality. The question for me is whether the package can be
(easily) built without that functionality if I so choose. If it
cannot, I continue to assert that the dependency is "Required".
I think that hacking the code (two headers and 3 c files, as well as
the man page, which is what all patch does, but without changing any
of the configure{,.*} scripts) and still having to hack configure in
some way is not a sane use of "Recommended" rather than "Required".
OK. I was just mentioning my understanding of "Recommended". In this
case, I agree with "Required".
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
