Ken Moffat wrote: > On Mon, Mar 03, 2014 at 02:43:17PM -0600, Bruce Dubbs wrote: >>>> >>>> 2. The following explain an optional --libexecdir switch: gnupg2, >>>> emacs, librep, geoclue. I don't have a problem with leaving this >>>> sort of thing in for a transitional period while people may still be >>>> using older versions of LFS (does 3 years sound about right?), BUT >>>> >>>> (i.) the markup is '<parameter>', I think it hould be '<option>' ? >> >> From a logical standpoint I think both fit. They are options to the >> ./configure command, but are also parameters in that they are a "set >> that defines a system or sets the conditions of its operation". >> >> However I do think our use should be consistent. In the html, option is >> inside of <code> constructs. We define that in the css to be monospace. >> For the parameter, we the text is inside <em><code> tags that render >> as monospace slanted on my system. We do not define em outside of a >> note, warning, etc. >> >> Which we choose probably doesn't make much difference. I would select >> option just because it is less keystrokes. >> >> In any case, I don't think it's enough of an issue to hold up release of >> BLFS-7.5. >> > I thought from an earlier reply that you considered these to be > leftovers from when we had --libexecdir=/usr/lib in the commands for > these packages.
We may be discussing two different things. Above I was addressing general '<parameter>' vs '<option>' usage. > So, I was going to delete them. If we don't use --libexecdir in a package, then I don't think it needs to be addressed at all other than the case when a new subdirectory is created in /usr/libexecdir. Then it's only documenting it fact that the subdirectory is created. > Now, I'll add this > for: colord, ConsoleKit, cpio, evince, git, gnome-terminal, the gstreamers, > icon-naming-utils, NetworkManager, vte, webkitgtk. I'll do a > separate commit, for ease of reverting it if needed. There might be > other packages, but I'm just going from what is in the ChangeLog. > > For consistency, it has to be an option. Compare e.g. the last > explanation [ --enable-slp ] in OpenLDAP. There used to be a lot > more examples, before people agreed that --disable-static should be > preferred. I actually think that monospace for options, but italic > for parameters is back-to-front, and perhaps increases the number of > false reports about a command being explained but not used, but > that's just another of the things about the book's XML which has to > be learned.. It's not italic, it's slanted -- at least in my browser. Since we don't define in the css what <em> is supposed to look like, then the browser decides. http://tex.stackexchange.com/questions/68931/what-is-the-difference-between-italics-and-slanted-text -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
