[blfs-dev] about subversion layout

Thomas Trepl thomas at linuxfromscratch.org
Sat Dec 28 13:57:18 PST 2013

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 

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 

Just my 2ct ;-)


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...

More information about the blfs-dev mailing list