Alexander E. Patrakov wrote these words on 03/06/08 10:39 CST: > 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",
It should be assumed that anything listed in the "Command Explanations" has been tested. Otherwise, the editor is just copying from ./configure --help output. > * logging the optional dependencies installed by the same editor, and To me, that is simply too much work for what is gained. Many dependencies are used for things specific to the dependency. Take Kerberos for example. If a package discovers that Kerberos is installed and creates binaries which link to the gssapi libs, that is dependency specific. If a build breaks because an optional dependency is, or is not used, then we'll have to hope this is identified via Trac or a mailing list. My point is that what difference does it make what options an Editor used? It may be that those options aren't required for the installer, or she simply doesn't want them. > * making his options suitable for copying and pasting together as a long > line. See above for this. What makes you think that because an Editor used specific options that someone else may want them? > 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. What is "useful" to one may not be to another. Correct me if I'm wrong, but we already provide a very nice cut and paste facility. If someone wants additional options, they add them. Perhaps I'm being hard-headed, but I just don't see the added value you speak of. > 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. This is beyond the scope of a 6.3 release. Let's worry about this if and when LFS changes direction. > 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. Agreed. > * Specify (where?) also options exactly as tested by an editor, in a form > easy > to copy and paste as a whole. I don't see value in this. I *always* use *all* optional dependencies for testing purposes when I update the book. I don't expect anyone to actually use them, but I test them. Would you care to see my Apache (64 configure options) or PHP (52 configure options) build scripts? Again, why is it important that it be identified what exact options the Editor used? If a build breaks for some reader, then we address the issue. It just seems like so much work to put this extra material in, when we don't know that those options are even desirable. > * 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). As previously mentioned, let's worry about PM when the time comes. Hopefully, there'll be input from others, as you and I have completely different ideas about this and perhaps we can find some middle ground. -- Randy rmlscsi: [bogomips 1003.22] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 11:34:00 up 18 days, 3:19, 1 user, load average: 0.39, 0.14, 0.04 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
