Lenny release goals for TeX
Table of Contents
We should drop the TDS compatibility hack from tex-common ASAP.
What else needs to be done? Should we somehow check all packages
that do not use dh_installtex (Build-Depend on tex-common) whether
This can be divided into a couple of sub-issues:
There are a couple of possible schemes and timelines to achieve this:
- Build libkpathsea4 from either TeXlive, or a separate pacakge
- Make sure that no package Depends on teTeX alone
- Make sure that TeXlive is always the primary choice
- Make sure that no package Build-Depends on teTeX alone
- Make sure that TeXlive is the primary choice for Build-Depends
- Make sure that all packages that (even indirectly) Build-Depend
on TeX have once been built with TeXlive, and have correct dependencies
We should decide which way we prefer, and contact the release team
before doing the final decision.
- With some warning in advance, drop the teTeX packages
completely, see what happens and deal with the mess
- Make the teTeX packages transitional packages, see what happens
and deal with the (much smaller) mess
- Find all packages that (Build-)Depend, Recommend or Suggest any
teTeX package, file bug reports and monitor how they are fixed; do
the same with respect to TeXlive being (not yet) the primary
- any other way to do it?
Completely clean up license situation
This involves checking all packages, the infrastructure is in
tpm2licenses.pl. Hopefully, Rogério and his students will
- Document the packaging better, so that the unititiated are able
to build a package from SVN.
- Package TeXlive 2006, at least.
- Decide whether TeXlive continues to work with conffile links and a
separate /etc/texmf/texlive, or switch to the teTeX
scheme, and implement if needed.
I don't think we should put much work in teTeX, except one thing:
We should inspect each bug on a teTeX package, and check whether it
should be closed or reassigned to TeXlive:
- Bugs that are clearly associated with teTeX packaging (including
some non-reproducible upgrading bugs) can be closed once teTeX vanishes
- Bugs that request features, file inclusions etc. can either be
closed if the wish is fulfilled in TeXlive, or should be
- Open bugs against packages or executables that also exist in
TeXlive should be reassigned/cloned.
- There'll probably a couple that don't fit into these
Whether we clone or reassign depends on the timeline of teTeX's vanishing.
Last modified: Mon Dec 11 14:33:51 CET 2006 .