Tushar Teredesai wrote:
> Additionally, the recommended thing is very subjective (i.e. based on
> who is updating the instructions). Sometimes when I go thru the book,
> I find that some optional dependency does not seem that useful. For
> example, arts lists libjpeg as a recommended dependency. Now why would
> I need a sound support application to link against a graphics library?
> That would mean I would have to recompile arts if the soname of
> libjpeg changed.
That example is not subjective. From aRts configure file:
{ echo "$as_me:$LINENO: WARNING: libjpeg not found. disable JPEG
support." >&5
echo "$as_me: WARNING: libjpeg not found. disable JPEG support." >&2;}
This is in spite of the fact that configure --help never mentions jpeg
and will build without it. Looking at the source, I don't see any calls
to a jpeg function in the aRts code.
Now what do we do? Change configure so it doesn't make an unnecessary
check for a package it doesn't need? That's a developer function, not
ours. Tell the user it is optional and let the warning shout that it
needs it?
According to kde, libjpeg is *recommended* for kdelibs, kdebase,
kdegraphics, kdemultimedia, and koffice. The easiest thing to do is to
just put it in aRts and keep configure quiet. It is recommended and
used in the next package (kdelibs) anyway.
The BLFS Book has the definition: "Recommended means that BLFS strongly
suggests this package is installed first for a clean and trouble-free
build, that won't have issues either during the build process, or at
run-time."
I don't see anything wrong with that. "strongly suggests" is the key
term. Who does the suggestion is implied: it is the editors of the book.
As for the why, the explanation given above is far too involved for the
book. Perhaps the whys of recommendations should go in the wiki.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
