We need new packaging solutions (was: Re: We need a new i18n doc build system)

[Christian Neumair <chris gnome-de org>]

Am Sam, 2003-08-09 um 17.52 schrieb Priit Laes:
> Thanks for bringing this up.
> 
> Christian Neumair kirjutas L, 09.08.2003 kell 14:32:
> > Proposals to solve those problems (maybe already for 2.6):
> >  - Have a system which generates language-specific xml files from our po
> > files, similar to gettext (add DOC_ALL_LINGUAS macro?).
> The autogen's DOC_ALL_LINGUAS should cooperate with some system wide
> variable, because user usually needs one or two translations of a
> manual.
> >  - Maybe add new groups/modules to i18n status pages (New
> > cat.:desktop-doc; New mod.: gnome-applet-doc, etc.)
> One more idea for future (Gnome3 maybe)
> *-doc packages (or *-doc-LANG):
>   - more freedom to documentation translators (and users), because they
> 	don't have to wait until the package itself is updated to new 	version.
> (something like: foo-doc-1.3-r2, if version of foo is 	1.3)
>   - reduced download time of the package itself (i assume that in
> 	Gnome3 we have lots of i18n'ed translations. If docs size is 	about 1
> MB  and we have about 5 or 6 translated variants it 	would suck up all
> the bandwidth and diskspace)
>   - when it comes to diskspace, the packages install all the translated
> 	locales to the system. (user usually needs one or two, rarely 	three on
> his/her machine) So it would be nice to have system 	wide variable or
> commandline argument which cooperates with 	autogen and installs
> documentation only for defined locales.
I think we have a few sane possibilities to package one software
product:

- Ship all in one package (basic + i18n + doc C + doc DOC_ALL_LINGUAS) -
CURRENT SOLUTION
- Ship docs separate (basic + i18n; doc C + doc DOC_ALL_LINGUAS)
- Ship only C docs bundled, i18n and i18n'ized docs in one extra package
(basic + doc C; i18n + doc DOC_ALL_LINGUAS)
- Separate out everything (basic; i18n; doc C; doc DOC_ALL_LINGUAS)
- Separate out translation of all core packages, ship i18n + i18n doc
separate (basic + doc C; gnome-i18n-LANG; gnome-doc-LANG).
- Separate out translation of all core packages, ship i18n + i18n doc
together (basic + doc C; gnome-i18n-LANG + gnome-doc-LANG).

I don't know what the best solution is, but separating out docs and i18n
packages seems to be most reasonable way to me. Separating our the docs
from the rest of the user-visible strings (doc X; i18n X) is in my
opinion braindead, since average users expect help buttons + docs to
work. Of course bundling everything in one GNOME package breaks our
completely modularized concept and forces each of the maintainers to do
tradeoffs, since the extra packages need to be released totally
coordinated, but for the sake of bandwidth (software definitly won't get
smaller) it seems to be a good solution. We'd have to force everyone to
release nano releases only until docs are sync'ed, e.g.
package-X-2.5.3.[i++]. package-X-2.5.[i++].0 releases would have to be
done together with the entire desktop and have the same version, even
for unstable versions, since docs + i18n files would have to be synced
up.
Another solution would be bundoing package-X-i18n-LANG and
package-X-doc-LANG packages + 1 GNOME metapackage-i18n-LANG + 1 GNOME
metapackage-doc-LANG which depends on all of them. This would still
enable us to be completely modular, but add dozens of new packages.
I think the debian guys prefer the latter - me, too.
Suggestions, comments, flamebaits? That's fine by me :)

regs,
 Chris

PS: Is this the right mailing lists for such ideas?