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

Re: documentation in additional packages



On Tue, Jul 04, 2000 at 08:50:27AM +0200, Ralf Treinen wrote:
[...]
> I'm trying to build a multi-binary source package which creates the binary
> package, and one documentation package for each of the supported formats.
> So, this makes
> 
> mozart mozart-doc-html mozart-doc-ps mozart-doc-pdf
> 
> My questions:
> 
> - does it make sense to provide ps and pdf ? Should I drop one, if yes
>   which one ?

Each of these would be several megabytes? In that case I'd rather drop one.
Note that each time you make a revision of the source package you get to
build and upload each of those binary packages, too, so...

PostScript and PDF seem to be near equivalent to the end user; so far
documentation in Debian has mostly been in .ps - from what I've seen; this
is just my impression, do check.

People who badly need the other format can always get the source and
generate it, although it's doubtful that there will be any of those :)

> - I could also partionate the documentation "vertically" that is
>   by subject of the documents into "tutorial", "reference", etc., and
>   provide the respective documents in all formats. Do you agree that
>   "horizontal" doc packages, providing all documents in one format at
>   a time, is a more sensible?

It depends on how many of them there will be (how many packages).

> - Should I provide a doc package in sgml, and if yes, what should go into
>   it and which tools could be used to access the doc in sgml (I'm quite
>   ignorant on sgml)

If you provide the SGML in a binary package, do it along with the output
formats... but if it's not necessary, leave the SGML out of binary packages.

> - A doc package, say mozart-doc-ps, should it put the documents in
>   /usr/share/doc/mozart-doc-ps/ps, or into /usr/share/doc/mozart/doc ?

Your choice... put handy symlinks into the other location.

-- 
Digital Electronic Being Intended for Assassination and Nullification



Reply to: