[blfs-dev] Upcoming BLFS-7.5 release

Bruce Dubbs 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
>> 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




More information about the blfs-dev mailing list