lenny release goals and the tetex->texlive transition
Dear all,
now that etch is frozen I start thinking about TeX-specific release
goals for lenny. A first draft is at
http://pkg-tetex.alioth.debian.org/
The most important question is to which extent and how we want to get
rid of tetex. The first step, however, shouldn't be controversial at
all: Make sure that all packages work with texlive. And actually it
wouldn't hurt to get some of those fixes into etch...
I am wondering whether we^I should start a mass bug filing on packages
that are missing a texlive alternative dependency
(Depends,Recommends,Suggests and also Build-Depends{,-Indep}. I am
currently collecting a list of packages. The next step would be to send
a mail to -devel about the mass bug filing, then to go ahead and see
what happens. The idea to send a mail to -release about etch-ignore
tags was also born in that context.
Here's a html2text output of release-goals-lenny.html:
****** Lenny release goals for TeX ******
***** Table of Contents *****
* General
o Enforce the TeX Policy in add-on packages
o Transition from teTeX to TeXlive
o Completely clean up license situation
* texlive
* teTeX
o Bug Cleanup
****** General ******
***** Enforce the TeX Policy in add-on packages *****
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 they comply?
***** Transition from teTeX to TeXlive *****
This can be divided into a couple of sub-issues:
* 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
There are a couple of possible schemes and timelines to achieve this:
1. With some warning in advance, drop the teTeX packages completely, see
what happens and deal with the mess
2. Make the teTeX packages transitional packages, see what happens and deal
with the (much smaller) mess
3. 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 choice.
4. any other way to do it?
We should decide which way we prefer, and contact the release team before doing
the final decision.
***** Completely clean up license situation *****
This involves checking all packages, the infrastructure is in tpm2licenses.pl.
Hopefully, Rogério and his students will help here.
****** texlive ******
* 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.
****** teTeX ******
I don't think we should put much work in teTeX, except one thing:
***** Bug cleanup *****
We should inspect each bug on a teTeX package, and check whether it should be
closed or reassigned to TeXlive:
1. Bugs that are clearly associated with teTeX packaging (including some
non-reproducible upgrading bugs) can be closed once teTeX vanishes
2. Bugs that request features, file inclusions etc. can either be closed if
the wish is fulfilled in TeXlive, or should be transferred.
3. Open bugs against packages or executables that also exist in TeXlive
should be reassigned/cloned.
4. There'll probably a couple that don't fit into these categories...
Whether we clone or reassign depends on the timeline of teTeX's vanishing.
Regards, Frank
--
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)
Reply to: