On Sat, Jan 11, 2014 at 10:21:28AM +0100, Igor Živković wrote: > On 01/11/2014 10:02 AM, Pierre Labastie wrote: > > > > 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. > > The way I see it, recommended classification should be used for: > > 1) dependencies that require explicit switch to disable at compile time > 2) system-installed dependencies which can be used instead of bundled ones > 3) dependencies that add a feature that is required to build some other > package in the book > > Everything else is either required or optional. There is nothing wrong > with listing and explaining optional dependencies in detail or fixing > packages to build with some optional feature. > I might subjectively recommend (4) anything which I consider improves the operation/usage of a package. At the moment, I don't have any examples but I'm sure there are several in the book. Or perhaps they have already been changed to "optional".
Two more comments - (i.) over time, everything changes. So some packages will be the way we used to do things, and others will follow what people think is current practice. And we will all make misjudgements. I'm not entirely sure that I understand Pierre's problem, and I'm happy to let everyone do as they wish - but I will question details if I think they are wrong or misleading. OTOH, the book is now in a far better state than it ever used to be (not just more packages, but generally up to date) and perhaps this would be a convenient time to enforce more order and consistency upon it - if that is what people wish to do. (ii.) the more we can explain, the better the book will be. Unrelated to the above, a bigger problem for maintaining the book is that we streamline dependencies so that A needs C but we don't mention that if A also needs B and B pulls in C. This does cause breakage if B is changed to not require C (happens occasionally - I'm thinking of things like pkgconfig moving to LFS, and therefore not implying glib2, but there have been other occasional examples. The obvious alternative is to list every dependency. That would make the rendered pages much longer (compare an rpm spec file for any significant package!) and I consider it would make the book much harder to read in a browser. So, I don't support it. But IFF people want to consider enforcing more order and consistency, perhaps we should also look at any other organisational changes in the book ? ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
