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".
ĸen - "mm, bikeshedding - love it"
--
This email was written using 100% recycled letters.
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
