Re: bc-1.03-8 uploaded
On Sun, 22 Oct 1995, Ian Jackson wrote:
> Bill Mitchell writes ("bc-1.03-8 uploaded"):
> > added /usr/doc/dc with dc.texinfo man Makefile
>[...]
> Why ? The texinfo file is a piece of source code and belongs in the
> source package.
Actually, I thought back to an exchange you and I had perhaps a
year or more ago regarding elv-vi.doc. You objected to the
separate doc package and said the compressed sources for the
docs should go in /usr/doc/elvis with a makefile.
I put this recollection together with a picture of a user who might
find printable documentation useful. /usr/doc seemed like the
appropriate place for that (installed with dselect, like everything
else). Since the distribution provides tools to get from a texinfo
file to a printable doc, I thought the texinfo file was appropriate.
I didn't even consider that the user might want to dig up a copy
of the source package, grub thru it, figure out how to build the
docs, and construct them manually. That seems to me like too
much to ask.
Looking in /usr/doc, I see that a number of other packages have
docs and Makefiles, though I seem to be alone at the moment in
providing a texinfo file for the Makefile to build from.
> The convention with all the other packages is to put the generated
> info file in /usr/doc/info.
I happen to read better horizontally than I do vertically. I don't
find info very useful, and find paperclipped manual pages more useful
than hyperlinks. Many of the people I work with likewise find printed
docs more useful than info. I don't think that's too uncommon.
> I think that if we want to distribute any other format we should put
> the formatted version in /usr/doc.
Compressed .dvi files? Compressed .ps files? I guess I could see
compressed .dvi files. (elvis1.8pl4 is an exception here, since
its documentation comes as .ms files. I've provided compressed
docs sources and a makefile for that in /usr/doc/elvis for some
time now.)
> In any case, it seems very unwise to put effort into changing all your
> packages in line with some new policy without first discussing whether
> the policy is a good one ...
Perhaps I did jump the gun here. It seemed reasonable at the time
(and, actually, still does). I'll adopt whatever consistent policy
may be established, but I think we should do more than say "dig the
raw material to build docs out of the source package if it's needed."
Reply to: