[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: