Am Samstag, 28. Dezember 2013, 12:25:02 schrieb Pierre Labastie:
> Le 28/12/2013 12:10, Fernando de Oliveira a écrit :
> > Em 27-12-2013 15:09, Fernando de Oliveira escreveu:
> >> Em 27-12-2013 14:53, Pierre Labastie escreveu:
> >>> Le 27/12/2013 18:28, Bruce Dubbs a écrit :
> >>>> Fernando de Oliveira wrote:
> >>>>> I promised Pierre to not change his modifications in subversion, but
> >>>>> every time I look at that page, I see that it is inconsistent with the
> >>>>> rest of the book.
> >>>>>
> >>>>> To Pierre: please, I would like you to agree with me and then I would
> >>>>> modify back subversion format (not dependencies nor technical parts).
> >>>>
> >>>> Yes, although it looks nice, it needs to be consistent with the rest of
> >>>> the book.
> >>>>
> >>>> -- Bruce
> >>>
> >>> I agree that it is not the same as the rest of the book, but the problem
> >>> I
> >>> faced was that usually, commands that are optional are inside <command>
> >>> tags, but "make swig-py..." is a two-line command, which does not fit
> >>> well inside <command> tags. OTOH, if those commands are put inside
> >>> <screen><userinput> tags, it is not consistent either, as it treats
> >>> them as recommended (or required) commands, so SWIG should be a
> >>> recommended dep.
> >>> It's not that I do not want to change, just that I have not found a
> >>> solution... But since I am very new to the book editing and Docbook, I
> >>> may
> >>> have missed something obvious.
> >>> So, go ahead.
> >>
> >> Thanks, Pirre and Bruce,
> >>
> >> I will do it tomorrow. I am done for today.
> >
> > Sorry, Pierre, above, s/Pirre/Pierre.
> >
> > Please, consider s/I am done for today/I need to stop now/, I think is
> > more polite.
> >
> > Fixed at r12465.
>
> It looks great. I did not know that <command> tags could be put inside
> <screen> tags.
>
> > I have kept the "screen" tags out of the tests.
>
> I understand that it is like that in the template.
>
> > Bruce, I noticed that the subversion page in BLFS-7.4 need to be
> > corrected, to include in the errata, something like:
> >
> > Replace
> >
> > make swig-py &&
> >
> > by
> >
> > make swig-py swig_pydir=/usr/lib/python2.7/site-packages/libsvn \
> >
> > swig_pydir_extra=/usr/lib/python2.7/site-packages/svn &&
>
> I think I can take care of that.
>
> Regards
> Pierre
Hi all,
I'm not really sure what this discussion is about (which means I'm not sure if
I got it right) but it sound like having trouble with optical appearance of
some sections. I'd like to add some thoughts.
If I don't totally misinterpreted the thread, its about how to format command
which are optional or only required under certain conditions. In this case its
about python and/or {perl,python,ruby}.
I'd like to have those commands formatted (optically) as all the other
commands ar formatted as well. That means <screen><userinput>...
To take care about the difference from required commands to optional one, the
descriptive text should explain what and why the command is optional. But if
it is relevant to the user, than the command should be typed exactly as it is
shown. That is how the <screen><userinput>-areas are described in the
introduction to the BLFS book.
There are a lot of packages in the book where optional commands are shown in
the (optically) same way as the required one. See polkit, for example. You can
build the whole system with or without PAM. In the polkit page, there are
command which are only meaningful when PAM is installed/used. Nevertheless,
the creation of the /etc/pam.d/polkit-1 file is shown in a <screen><userinput>-
format, just as the other commands are, too. The descriptive text is what
makes the difference.
So i think every command that shows the user how things are done should be
<screen><userinput>-formatted. But it is also important to describe the fact
that some my be optional and if so, under which conditions. Only commands
referenced in a descriptive text sections may be formatted as <command>, but
my understanding is that those texts need not to be fully complete as they may
be used as pointers like "When specifing XY in the <command>configure</command>
above, then ..." The text embedded in the command-tags is never meant to be
copy-pasted.
BLFS does not tell the reader step by step what is needed to be done as LFS
does. There are too many alternatives beyond LFS. With the learnings from LFS,
the reader of the BLFS book should know by {her,him}self whether ruby is
installed and therefore the commands to create the svn-ruby bindings are
relevant for {her,him} or not. The descriptive text should give good hints for
this decision.
So, finally I think the decision is right to put the commands at least in a
<screen>-section.
Just my 2ct ;-)
--
Thomas
Btw, I'm impressed by the performance especially Pierre, Fernando and Igor are
showing. The book seems to catch up to the bleeding edge and keeps being there
;-) Thanks for this work!
I'm just on the way to compile KDE-4.12.0 (on a completely DESTDIR-installed
system) but I'm sure some of you will be faster to have results...
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
