[blfs-dev] 1st attempt

Ken Moffat zarniwhoop at ntlworld.com
Mon Mar 11 19:34:57 PDT 2013

On Tue, Mar 12, 2013 at 02:09:30AM +0100, Jean-Philippe MENGUAL wrote:
> Hi,
> At http://demo.accelibreinfo.eu/dotconf.tar.bz2
 Putting a single file in a tarball allows you to easily compress
it, but it's only 5K anyway.

 I can't render a single file because all the "control" goes into
the "section" pages, e.g. general/genlib/genlib.xml with the package
version entity in general.ent at the appropriate place.  I suggest
that you do that (I'm guessing general/genlib _might_ be
appropriate, but I've really no idea).  If you are in doubt about
where to put anything, use the list for discussion.

 Putting the version in general.ent also means that we use an entity
for the package version in the download entit(y,ies) of hte page.

> you will find my 1st attempt of xml file. I add thus dotconf 1.0 to the
> book. It's a dependency of speech-dispatcher (I'll finish soon), speech-dispatcher
> is a dependency of orca. It helps too for brltty. It is used often in
> speech-to-text technologies.
> I wait for your 1st feedbacks. My main issue now is describing the installed libraries.
> How do you do? Is my list too precise (I put everything is installed)?
> I really would appreciate your help about this part of the xml file (methods,
> ideas, generic description). Binaries are not always easy to describe, but libs...
> I nearly cannot figure out how we can do.
 For descriptions, you'll find that some things, particularly
some libraries, are not described - if there is easily available
text (sometimes, a description in another distro, other times
perhaps in the package itself) it's easy to paste it.  If there
isn't, and I've no idea what it is, I'll google, and if nothing
comes up I won't describe it.

 I see there are two static libs : would using --disable-static
remove them ?  If so, please add that unless there is a reason to
require a static lib.

 You seem to have a dotconf-kernel section, but a quick look
suggests it has no content.  When you render, I assume this will
show up in the kernel part of longindex,html, but without any
content.  Most packages don't need kernel sections - not everything
in the template is relevant to every package.  Actually, all the
TEMPLATE references need to be changed - look at any other package.
Also, the comment 'Place this in the general.ent file' can go :)

 Similarly, we normally make a choice of the items in curly brackets
{...} in the Contents segtitles.  So 'Installed Program' and
'Installed Libraries' (the alternative would be Library - singular).

 For the list of installed libraries, omit la files and limit the
list to libpool.a (if it is required) libdotconf-1.0.so or
libdotconf-1.0.{so,a}.  Hardcoding versions (10.4 in this case) is
asking for things to get out of date.  Often, .so or {.so,a} is all
that needs to be mentioned - in this particular case the -1.0 is
probably worth noting.  Alphabetical order would be better [ for
the dependencies I'm ambivalent about order - in big packages it is
sometimes easier to list them in the order in which configure
mentions them ].

 Hmm, no installed directories.  Perhaps correct (if the header(s)
go into /usr/include directly).  I'm just looking at existing random
libraries in genlib to see what we usually do ;-)

 We only normally mention symlinks for _programs_ invoked by
different names.  I'm sure there are other things, but the hardest
test is usually getting it to render at all.  I can't tell if you've
done that or not.  The normal procedure is to make a patch (add
package to the chapter, change the chapter xml to ensure it renders,
add it to general.ent : ChangeLog and date details can be left for
whoever commits it).

das eine Mal als Tragödie, das andere Mal als Farce

More information about the blfs-dev mailing list