gene.heskett at verizon.net
Sun Mar 4 19:01:53 PST 2007
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
>> 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$'.
>>> 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
>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.
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.
"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.
More information about the xorg