Splitting a package between doc and binary
Peter S Galbraith asks:
> The gri package for i386 is 2MB in size. About 3/4 of that are
> docs suitable for all archs.
>
> Should I split the package to save space on servers (sharing the
> doc) and keep it as is to reduce name space and number of
> packages?
>
> I do think most gri users will want the docs (especially since
> it's a programming language, so users need to learn it). But
> perhaps a minority of users would upgrade the binary package and
> not necessarily the docs package as often if they were on a modem
> connection.
You should definitely split off the documents, in fact split it in three as
explained below.
Reason: in practice most "users" of exotic programming languages (i.e.,
anything not in {C,C++} :) turn out to be "indirect users", i.e., users
that only download the language because some other package depends on it.
(Please read on before refusing this.)
Thus a programming language L usually comes in three packages:
1. Absolute minimal "L-base" package in either the interpreters or libraries
section (as appropriate) with what is needed to run L-programs written
(and compiled, if appropriate) by someone else.
This is what packages using L should depend on.
2. "L-dev" package the compiler and what is needed to compile (and link, if
appropriate) programs in the language.
This is the package that other packages containing (or generating)
L-source programs will depend on.
3. "L-doc" package with the documentation for "real" users of L.
No-one depends on this package but it could be "Suggest:"ed by L-dev.
Remember: don't think to small -- if the gri programming language is worth
using it is worth making packages with it. This means that there will be
indirect users in the sense above.
Best regards,
Kristoffer
--
Kristoffer Høgsbro Rose, phd, prof.associé <http://www.ens-lyon.fr/~krisrose>
addr. LIP, Ecole Normale Supérieure de Lyon, 46 Allée d'Italie, F-69364 Lyon 7
phone +33(0)4 7272 8642, fax +33(0)4 7272 8080 <Kristoffer.Rose@ENS-Lyon.FR>
pgp f-p: A4D3 5BD7 3EC5 7CA2 924E D21D 126B B8E0 <krisrose@{debian,tug}.org>
Reply to: