[blfs-dev] Upcoming BLFS-7.5 release
bruce.dubbs at gmail.com
Mon Mar 3 17:27:06 PST 2014
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
> 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
More information about the blfs-dev