Hello, Sorry for the long post. So for the impatient, the question is: why does the book have instructions for optional (not recommended) features? And what is the difference between optional and recommended if instructions are given for both? [Long version] I am having some doubt about the distinction between 'recommended' and 'optional' brand for dependencies, and their relation with what is in the instructions. Here is what I had understood: - Required: the package cannot be built without that dependency, whatever tweaking you apply. - Recommended: The instructions which follow suppose that dependency is installed. It may be useful for building other packages depending on the one we are building right now, or it adds features that the editor has deemed interesting. If the user wants to omit them, she is on her own: either the instructions on the page may not work, or it will be impossible to build a package later. - Optional: The package we are building depends on that dependency for added features, which the editor either has not tested, or does not consider so useful for the general user, or does not want to maintain the instructions for, or is not aware of. The user may build this added feature, but again, she is on her own for that. Some indications may be given in the "Command Explanation" section. The related switches appear with a different layout.
Now, for me, the question is whether instructions for optional features should be given or not. In some way, it is some kind of schizophrenic attitude to deem something as optional, then test it and give the instructions for. Of course, it is clear that all the editors know much more than what is in the book, but what is the book for? One could of course dream of showing all that can be done when building a GNU-Linux system from scratch. But it is rather hopeless, or would demand much more manpower for maintenance (Debian repositories have roughly 30,000 packages, that's almost 2 orders of magnitude more than the book...). I think the book should show well chosen examples in various domains (security, networking, etc, well, see the list of chapters), with the aim of showing enough so that a user may be able to build other packages in the same domains, and to find documentation by herself. Actually, the present book allows slightly more, since there are enough packages for building a fully operational development desktop system. Yet I see more and more places where instructions are given for some feature, while the associated dependencies are in the optional paragraph. One recent example is transcode, where instructions have been recently added for using freetype2, while freetype2 is in the optional deps (Fernando, please, do not be upset: it is just an example). Another example is subversion, where there are a bunch of instructions for building the bindings, all of which are considered optional. So I'd like to clarify what the criterion is for adding instructions for optional features, if not adding all of them. For examples in the other direction, many instructions for building API docs with doxygen, which were considered optional too, have disappeared in the last year or so. [conclusion] I'd like to know when instructions for optional features should be given, and when deemed such, why they should not be moved to recommended instructions. Regards, Pierre -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
