On Fri, Oct 21, 2005 at 16:28 +0200, Frank Küster wrote: > regarding tetex-bin > > a) #78926: If possible, it'd be nice if dvips were a seperate package, > so that users of printfilters, e.g., don't need tetex-bin installed. > > [is this really a realistic scenario? How many systems are there that > print dvi, but don't produce it?]
This might happen on a dedicated print server. However, dvips alone won't be of much use. One would also need fonts, metrics etc and the infrastructure for finding them. Under such circumstances, the overhead of other binaries from tetex-bin becomed negligible IMO (at least for tetex-bin-nox). > I expect that teTeX will continue to be the standard package for > creating documentation when building a Debian package, and I think that > we should try to develop our splitting schemes mainly along the needs of > this application. End users will probably just install everything, or > switch to tex-live. I think we should already think about the coexistance with TeX Live. I don't know if there are many TeX Live packages that don't include files that are also in teTeX. And how to be sure that the dependencies speciefied by some TeX Live package are fulfilled by the teTeX packages installed? [...] > * minimal scheme > ^^^^^^^^^^^^^^ > tetex-bin is split into tetex-bin-nox and tetex-bin-x11; tetex-bin > continues to exist as a dummy package. Besides sorting files with dh_* > and writing the necessary control information, the only thing we have to > do is connected to mf: we probably need to set up an alternatives system > for mf-nowin and mfw. Sounds reasonable to me. > For tetex-base, the additional splitting-off of a type1-fonts-x11 > package can be added to both following splitting schemes: > > * minimal scheme > ^^^^^^^^^^^^^^^ > Just move PSNFSS and the Bluesky fonts to tetex-base (e and d, #324868, > #302035) and be done. The MF sources of the EC fonts are also necessary. But all this would increase the already to large tetex-base. I think we need the > * advanced scheme > ^^^^^^^^^^^^^^^ > Alternatively, we could create a tetex-base that is in fact a > latex-base: > > As Ralf has pointed out, tex/latex has a size of 16Mbyte, while 94Mbyte > of the total of 135 Mbyte (without doc) are in the fonts directory. > Therefore it seems that it doesn't help much to figure out which LaTeX > packages are needed in this new base package. Instead, we include in it > > - the complete tex/latex directory, Actually some directories with font support should go to tetex-extra (lucidabr, txfonts, pxfonts, ...). If one has to split tex/latex anyway, one might also move some large packages that probably aren't used as build-dependence. Incomplete list with decreasing size: custom-bib, koma-script, minitoc, jurabib, memoir, ntgclass ... > - everything else that is needed to run LaTeX and plain TeX. (at least that's what the policy says IIRC) > - input files for makeindex and bibtex. I'm not sure about all those > bst files. I would say bibtex/bst/base and maybe bibtex/bst/ams (I am not sure if those are also a 'required' part of LaTeX) should be in tetex-base. The rest might go to tetex-extra. The difficult part is to keep things together that belong together, like bibtex/bst/revtex4 and tex/latex/revtex4. > - PSNFSS fonts, the CM and EC fonts in Metafont and Type1 format, if > available. To what extend do we want internationlization? Should people be able to produce documentation in Russian, Greek or Vietnamese with tetex-base alone? > In case we end up implementing the advanced scheme for both source > packages, we also need to think about dependencies - I think in this > case tetex-bin-extra should *depend* on tetex-extra, so that people > won't end up with texexec but no context input files, and similar > situations. ACK > Maybe we should also rename tetex-base (e.g. to tetex-latexbase), but on > the other hand I don't expect that many packages that depend on > tetex-base only would stop working; the harder part would be to convince > package maintainers to drop the tetex-extra dependency. Maybe it would beintersting to get maintainers of (build-)depending packages involved. We aim at making tetex-extra unnecessary as build dependence. Therefore, the maintainers of (build-)depending packages could tell us what they are actually using from tetex-base and tetex-extra. > If you like, we can start coding at once, using a branch in the svn > repository. Unfortunately I won't have much time in the next 1½ months. :-( cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
