On Mon, Dec 09, 2002 at 01:05:01PM -0600, Adam DiCarlo wrote: > I think it might be right to have a cut-off point like this. I would > object rather strenuously to a DDP policy that required pkgs split by > language. Ok. I will give it a thought. We might find some middle ground.. > > The upside of pkg splitting by language: > > - smaller pkg size > > The downside: > > - harder for maintainers As a matter of fact I was thinking on having the CVS automagically create the packages as soon as new versions are available (with proper debian/rules templates available in CVS too). The maintainer would only have to upload them. If you give templates for Makefiles (we currently have a mess but they could _all_ be the same, after all they just compile SGML sources) _and_ for package builds then the maintainers need not worry. > > - more possibilities of bugs Probably not it done right (See above). > > - more work for archive maintainers (kinda) Only on the first upload (new packages). > > - confusion for users I, as a user, feel less confused by a manualname-XXX package (with XXX something I identify as my language) than by a manualname package which I'm not sure provides a translation that is useful for me. The current best practice, for some documentation packages, is to provide -XXX packages. Not only when we are talking about documentation, try this: apt-cache search --names-only -- "-(de|es|ja|fr|ru|pt|ko|fi|en|hr|zh|cs|it|ca)$" (and I have not included all the available languages in the list) IMHO we should keep it this way. In any case, it might make sense to say something on the lines of: "For documentation which does not exceed XXX lines (or XXX kbytes of compiled formats) packages should include all the available translations. Binary Packages which are over XXX of size, however, should be broken into several packages (one per language) following the convention: packagename-XX which XX being the ISO code for the given language." Regards Javi
Attachment:
pgpq7O3gyuPbw.pgp
Description: PGP signature