Randy McMurchy wrote: > Alexander E. Patrakov wrote these words on 02/27/08 09:15 CST: > >> (Yes, that's a request to change the policy about configuration options that >> require optional packages, that's why I am cross-posting to blfs-dev. My >> proposal is to list the options that the editor has used, and, below that, a >> list of optional dependencies that they imply as a minimum, and a list of >> optional dependencies actually installed by the editor who updated the page.) > > It's my preference (note I only say a preference, but the community > will be the final authority) to keep the policy we have intact. > > I don't see the harm in using a basic ./configure line which does > not pull in optional dependencies. If this configuration has limitations > and/or problems, then we identify it and let the *installer* choose > what to do.
[words written before reading the bottom line of Randy's mail, ignore them, because the minimal options have to be determined anyway, see below] Sure, but then we should do this procedure twice: once (implicitly) for the configuration that the editor uses, and one (just for the book) for the "minimalistic" configuration that doesn't pull optional dependencies. [end of wrong words] > A mention of what configuration options were used by the Editor in > the Command Explanations section would be fine, which we essentially > do now. Yes, this place also is suitable for placing options that the editor uses. What's not done is: * marking the set of options in "Command Explanations" as "tested and known good", * logging the optional dependencies installed by the same editor, and * making his options suitable for copying and pasting together as a long line. > I suppose I'm just not understanding the technical merit we'd gain > by doing things differently. I'd rather we keep the way we've done > it as it shows the reader a basic configuration. It's up to the > reader to use additional options identified in the Command Explanation > section, and/or ./configure --help output. The technical merit is, as I explained, in defaulting to a known good, tried and useful configuration that is easy to copy and paste as one large chunk. Also, I expect the "known good" options and dependencies to go by default to spec files of their equivalent, when package management enters the book. > It's my opinion that if we were to start adding in stuff to the > ./configure line, then a reader may assume that you *must* do it > that way or things won't work properly. Thanks, this note clarifies your viewpoint a lot, and is certainly valid. My original proposal sucks (because it doesn't differentiate between truly mandatory options and the rest of options in the "known good" setup). Let's improve it, so that it takes both viewpoints into account: * Specify truly required options in the same place as we do it now. * Specify (where?) also options exactly as tested by an editor, in a form easy to copy and paste as a whole. * Specify (where?) optional dependencies used by that editor, because they are also a part of the description of the "known good" setup (possibly, to be later reproduced by a package manager that can't read anyone's mind). -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
