[ANNOUNCE] xorg-sgml-doctools-1.2

[Gene Heskett]

On Sunday 04 March 2007, Ben Byer wrote:
>On Mar 4, 2007, at 2:41 PM, Gene Heskett wrote:
>> On Sunday 04 March 2007, Daniel Stone wrote:
>>> Users never deal with DocBook.  Full stop.
>>
>> Oh?  Maybe you should tell the packagers that, lots of stuff ships
>> with
>> only a docbook subdir in the tree.
>
>Which? What exactly are we talking about, here?
>
>> [...]
>>
>>>>> So, I don't see any problem at all.
>>>>
>>>> Obviously you are privy to the secret incantations to make it
>>>> work.  I
>>>> would like to join that club but my attempts to carve a working key
>>>> have so far, been both very frustrating, and an utter failure.
>>>
>>> I can see why, because you're attempting to solve the wrong problem.
>>>
>>> As an aside, I tend to lose interest whenever I see 'M$'.
>>> Particularly
>>> if the analogy makes no sense.
>>
>> Mmmm, was not Framemaker an M$ product?  Popular back about the
>> same time
>> FrontPage managed to break every browser on the planet that
>> expected w3c
>> validated input?  Please correct me if that's not a correct
>> assumption on
>> my part.
>
>Try Adobe. http://en.wikipedia.org/wiki/FrameMaker
>
> From your later emails, it looks like you might have realized this,
>but just in case, I'll try:
>
>DocBook is a compiler for documentation, much like GCC is a compiler
>for C code.  (Note that both of them have complicated command-line
>syntax!)
>
>1. You (as a user) never see DocBook data; you get man pages (and
>sometimes online help in HTML).  Much like how users generally aren't
>expected to "run" C source files.
>
>2. You (as a developer) use a text editor to edit the XML-format
>DocBook files without worrying about how to make pretty HTML or groff-
>formatter manpages, because DocBook takes care of it.
>
>3. You (as someone who uses bleeding-edge source releases from git,
>etc) should just be able to run "./configure && make && make
>install", and it should magically make and install man pages for you.
>
>Hope this helps -- #1 should work just fine; if #2 and #3 are
>problematic, then maybe we have some work left to do.
>-b

Perhaps I'm still miss-understanding how it works.  The program tree I was 
referring to above was the amanda-2.5.1p3-20070222 snapshot.  I did not 
do anything unusual other than my usual ./gh.cf script that I use to 
drive the configure program with consistent options data, this scripts 
last line is make.  The tree has a docs dir that is all .txt files.  It 
has, in this same root of its srcs dir, a man directory, which now 
contains all the manpages, dated when I built it on feb 22nd.  Within 
this man dir is an xml-sources dir, and all the files there are much 
older, so they came from the tarball.  Ergo the manpages I see there were 
built by the main Makefile which in turn sourced the Makefiles in those 2 
dirs and built the manpages.  They did it fairly quietly, so all I 
actually noticed was the manpages being installed.  My mistake.

Now I understand that much better than before, but it obviously becomes 
the packagers responsibility if I were to type 'man fetchmailrc' and get 
told it doesn't exist.  It does of course, but that's an example only.

Now, I would like to thank you all for your patience and guidance, and 
I'll shut up till I have a real problem, hopefully not involving the kind 
people at xorg the next time.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2007 by Maurice Eugene Heskett, all rights reserved.