Is there a chance for teTeX-3.0 in sarge?
Hello,
nobody knows when sarge will eventually be released. I think the 2.0.2
packages are in fairly good shape for sarge, so we are prepared even for
a really fast release (although we'll probably not see the table dance
by some DD's on CeBiT, promised should the freeze start during the
fair). On the other hand, I think we should also be prepared for an
other couple of months waiting for infrastructure. The successful
effort made by the KDE team to get a new version into sarge has given me
hope that we might manage it, too.
I have written a text about this which is at
http://people.debian.org/~frank/teTeX-3.0/
(and in debiandoc-sgml at
http://cvs.debian.org/tetex-common/teTeX-3.0-in-sarge.sgml?cvsroot=tetex).
Here I will cite some important parts, and comment on them. I'll also
attach the complete document in text format (actually, debiandoc2textov,
a little troff'ed) for those who don't have web access when they read
the mail.
Waiting for your critical answer,
Regards, Frank
,----
|
| Is there a chance for teTeX-3.0 in sarge?
|
|
| 1. Why do we want teTeX-3.0 in sarge, and why not?
|
| The tetex packages have two rather different areas of application,
| with very different demands. One is the typesetting of code that has
| been generated from various sources, like debiandoc-sgml, docbook,
| texinfo, and so on, often the documentation of Debian packages or a
| data output format of a program. The other is the usage by authors who
| choose a particular TeX format, e.g. LaTeX or ConTeXt to write and
| typeset their documents - theses, manuals, reports, critical editions,
| and increasingly screen presentations.
|
| The first application, typesetting of generated code, hardly ever uses
| any recent features of the formats, or of add-on packages, and its
| main demand is stability. This is of particular importance for
| Debian's package building system - teTeX is a direct or indirect
| build-dependency of many, many packages. Therefore, any breakage
| caused by a change in teTeX might have a fatal impact on the release
| process, no matter whether it is caused by a bug in teTeX, or by
| revealing a bug in an other package.
|
| The second application, on the other hand, often requires the use of
| recent versions of the basic TeX engines, the formats (LaTeX, ConTeXt,
| etc.), and any add-on-packages. TeX and LaTeX are famous for their
| stability and compatibility across versions. However, compatibility in
| this context means that ancient documents still give identical output
| today; newer documents will still rely on new features. There has been
| considerable development in the TeX area in the last years, and in
| fact the version of teTeX that is currently in sarge, 2.0.2, cannot be
| recommended for most serious typesetting except for generated code,
| without some major local updates.
|
| In summary, from the point of view of package building, there is no
| reason for inclusion of teTeX-3.0 in sarge, but there are many
| caveats. On the other hand, for people who want to use teTeX directly,
| we can only recommend not to use the version currenty in sarge.
`----
Nothing to add here. Then comes the part "General considerations:
Problems and ways to check for them", first discussing "What has changed
between 2.0.2 and 3.0?", then shortly the current status - I won't cite
that here. Then comes
,----
| 2.3. Problem areas to look at
|
| 1. Packages directly build-depending on teTeX
|
| These Packages should be autobuilt on at least one architecture.
| The successfully built packages should at least be checked with
| debdiff whether there are significant changes compared to the
| ones unstable. A complete list of these packages is included in
| Chapter 3, `Detailed listing of tasks'
|
| 2. Code generators, and packages depending on them
|
| Most code generators should have packages build-depending on
| them. These packages, which indirectly build-depend on teTeX,
| should be treated just as directly depending packages. It must be
| checked whether at least one of those packages actually uses the
| TeX backend.
|
| Code generators that do not have build-depending packages should
| be tested separately.
|
| 3. Binary dependencies on teTeX
|
| This is the most difficult part to automatically check. It must
| be hoped that some people use teTeX from experimental, and that
| in particular we can pursuade the maintainers of these packages
| to try it out.
|
`----
I am currently trying to set up an autobuilder (i386) on a machine I
own, but keep having problems with that (see
http://lists.debian.org/debian-devel/2005/02/msg01287.html and later
http://lists.debian.org/debian-devel/2005/03/msg00172.html,
http://lists.debian.org/debian-devel/2005/03/msg00349.html - haven't had
time to investigate the answer to the last one).
The box has a flatrate, but only 100kbit/s (that's what I paid, often
it's 120, sometimes less).
Finally, the document ends with a list of packages that need
autobuilding. This is just the contents of the files
Build-Depends-on-base
Build-Depends-on-base.nonfree
Build-Depends-on-base_oneline
Build-Depends-on-base_oneline.non-free
Depends-on-base
Build-Depends-on-bin
Build-Depends-on-bin.nonfree
Build-Depends-on-bin_oneline
Build-Depends-on-bin_oneline.non-free
Depends-on-bin
in http://cvs.debian.org/tetex-common/?cvsroot=tetex, which I got
with grep-dctrl. It does not yet include any indirect build-deps,
i.e. no packages that build-depend on docbook-utils, jadetex, etc.
Regards, Frank
--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer
IIss tthheerree aa cchhaannccee ffoorr tteeTTeeXX--33..00 iinn ssaarrggee??
----------------------------------------------------------------------------------
Frank Küster <frank@debian.org>
version 0.1, 2005-02-23
-------------------------------------------------------------------------------
AAbbssttrraacctt
This document discusses the risks and chances associated with a
possible inclusion of teTeX version 3.0 in Debian sarge, what must be
done before this can really be hoped, and how far we got until now.
CCooppyyrriigghhtt NNoottiiccee
Copyright (C) 2005 Frank Küster
This text is in the public domain.
-------------------------------------------------------------------------------
CCoonntteennttss
1. _W_h_y_ _d_o_ _w_e_ _w_a_n_t_ _t_e_T_e_X_-_3_._0_ _i_n_ _s_a_r_g_e_,_ _a_n_d_ _w_h_y_ _n_o_t_?
2. _G_e_n_e_r_a_l_ _c_o_n_s_i_d_e_r_a_t_i_o_n_s_:_ _P_r_o_b_l_e_m_s_ _a_n_d_ _w_a_y_s_ _t_o_ _c_h_e_c_k_ _f_o_r_ _t_h_e_m
2.1. What has changed between 2.0.2 and 3.0?
2.2. Current state of the teTeX-3.0 packages
2.3. Problem areas to look at
3. _D_e_t_a_i_l_e_d_ _l_i_s_t_i_n_g_ _o_f_ _t_a_s_k_s
3.1. Already completed
3.2. To be done
-------------------------------------------------------------------------------
11.. WWhhyy ddoo wwee wwaanntt tteeTTeeXX--33..00 iinn ssaarrggee,, aanndd wwhhyy nnoott??
The tteetteexx packages have two rather different areas of application,
with very different demands. One is the typesetting of code that has
been generated from various sources, like ddeebbiiaannddoocc--ssggmmll, ddooccbbooookk,
tteexxiinnffoo, and so on, often the documentation of Debian packages or a
data output format of a program. The other is the usage by authors who
choose a particular TTeeXX format, e.g. LLaaTTeeXX or CCoonnTTeeXXtt to write and
typeset their documents - theses, manuals, reports, critical editions,
and increasingly screen presentations.
The first application, typesetting of generated code, hardly ever uses
any recent features of the formats, or of add-on packages, and its
main demand is stability. This is of particular importance for
Debian's package building system - tteeTTeeXX is a direct or indirect
build-dependency of many, many packages. Therefore, any breakage
caused by a change in tteeTTeeXX might have a fatal impact on the release
process, no matter whether it is caused by a bug in tteeTTeeXX, or by
revealing a bug in an other package.
The second application, on the other hand, often requires the use of
recent versions of the basic TTeeXX engines, the formats (LLaaTTeeXX, CCoonnTTeeXXtt,
etc.), and any add-on-packages. TTeeXX and LLaaTTeeXX are famous for their
stability and compatibility across versions. However, compatibility in
this context means that ancient documents still give identical output
today; newer documents will still rely on new features. There has been
considerable development in the TTeeXX area in the last years, and in
fact the version of tteeTTeeXX that is currently in sarge, 2.0.2, cannot be
recommended for most serious typesetting except for generated code,
without some major local updates.
In summary, from the point of view of package building, there is no
reason for inclusion of teTeX-3.0 in sarge, but there are many
caveats. On the other hand, for people who want to use tteeTTeeXX directly,
we can only recommend not to use the version currently in sarge.
-------------------------------------------------------------------------------
22.. GGeenneerraall ccoonnssiiddeerraattiioonnss:: PPrroobblleemmss aanndd wwaayyss ttoo cchheecckk ffoorr tthheemm
22..11.. WWhhaatt hhaass cchhaannggeedd bbeettwweeeenn 22..00..22 aanndd 33..00??
Using e-TeX as engine
One major change has actually already been made to version 2.0.2
by the Debian maintainers: According to the recommendation by the
LaTeX team, the engine used for LaTeX is now e-TeX, and the
engine for pdfLaTeX is pdf-e-TeX. Consequently, the format files
have the extension ..eeffmmtt. As a workaround for packages that
expect the old extension ..ffmmtt, or for packages that directly call
the engine, the generation of the old formats has additionally
been enabled in 2.0.2. In 3.0, the extension is ..ffmmtt irrespective
of the engine. Therefore the format file extension is no issue;
however packages that call the engine directly have to be fixed
(see: ##226633229966,, ##226644004433).
Using pdf-e-TeX as engine
In teTeX-3.0, engines have further been changed: Now pdf-e-TeX is
used both for LaTeX and pdfLaTeX, once in DVI output mode, once
in PDF mode. There is one problem here: Some input files might
still use a buggy check for PDF mode vs. DVI mode, assuming that
only standard TeX can produce DVI, and using PDF specials as soon
as \\ppddffoouuttppuutt is _d_e_f_i_n_e_d. The correct check would be whether it
is set to 11 (true, PDF), or 00 (false, DVI).
Input files that use such a buggy test might give an error, or
under some circumstances might produce the wrong output format.
For packages that Build-depend on tteetteexx, a test build and a check
with ddeebbddiiffff will reveal the problem. Packages that Depend on
tteetteexx have to be checked manually.
TeX Directory structure
There have been rearrangements in the TeX Directory structure.
This mainly affects font file placement. The existing packages of
teTeX-3.0 have already been patched to accept files in their old
locations.
Stricter behavior of uuppddmmaapp
In 2.0.2, the updmap script issued a warning when a map file that
was referenced in uuppddmmaapp..ccffgg could not be found. In 3.0, this
warning was turned into an error. Such an error will always occur
when a package is removed, but not purged, leaving its
configuration information in uuppddmmaapp..ccffgg. Although there is a
proposal and a reference implementation for a mechanism to
cleanly solve this problem, for sarge this error would have to be
reverted to a warning by a Debian-specific patch.
lliibbkkppaatthhsseeaa soname change
The soname number of lliibbkkppaatthhsseeaa has changed from 3 to 4. Since
the API of libkpathsea is only badly defined, adapting packages
that depend on it to the new version is not feasible for sarge.
For this reason, we are planning to upload a new version of the
tteetteexx--bbiinn__22..00..22 sources, with the source package name
lliibbkkppaatthhsseeaa33, that only produces the lliibbkkppaatthhsseeaa33 and
lliibbkkppaatthhsseeaa--ddeevv packages. This source package already exists, and
produces binary packages identical to the ones currently in
unstable.
I am currently not aware of any other changes that could cause
breakage. If you find any, please notify me.
22..22.. CCuurrrreenntt ssttaattee ooff tthhee tteeTTeeXX--33..00 ppaacckkaaggeess
Currently (2005-03-06), packages for teTeX-3.0 are only available in
experimental.
The packages can be installed or upgraded from current sarge without
problems, and provide upgrade paths for some configuration files with
changed location and/or syntax. The packages have not yet been
practically used a lot.
22..33.. PPrroobblleemm aarreeaass ttoo llooookk aatt
1. Packages directly build-depending on tteeTTeeXX
These Packages should be autobuilt on at least one architecture.
The successfully built packages should at least be checked with
debdiff whether there are significant changes compared to the
ones unstable. A complete list of these packages is included in
Chapter 3, `Detailed listing of tasks'
2. Code generators, and packages depending on them
Most code generators should have packages build-depending on
them. These packages, which indirectly build-depend on teTeX,
should be treated just as directly depending packages. It must be
checked whether at least one of those packages actually uses the
TeX backend.
Code generators that do not have build-depending packages should
be tested separately.
3. Binary dependencies on tteeTTeeXX
This is the most difficult part to automatically check. It must
be hoped that some people use teTeX from experimental, and that
in particular we can pursuade the maintainers of these packages
to try it out.
-------------------------------------------------------------------------------
33.. DDeettaaiilleedd lliissttiinngg ooff ttaasskkss
33..11.. AAllrreeaaddyy ccoommpplleetteedd
The following packages that directly build-depend on tetex-base have
already succesfully been built:
tetex-bin
33..22.. TToo bbee ddoonnee
This is the list of packages that directly build-depend on tetex-bin,
and have not yet been tried:
a2ps acl2 adolc advi aleph am-utils apcupsd autogen axiom bison bison-1.35 blas blitz++ boa cameleon cernlib cfitsio chktex cl-tclink clif crystalspace ctie cvsbook cweb cwebx cxref darcs doc-debian-es dvipdfmx ecartis ecasound2.2 emwin esh fdutils flite fpc freefem freefem3d gcc-3.2 gcc-3.3 gcc-3.4 gcl gclcvs gdb geomview glame glosstex gmsh gnat-glade-doc gnat-gps gnucap gnuplot gocr gorm gpm gprolog gpsbabel gretl gri hyperlatex ifhp iproute kdegraphics laptop-net libcaca libgcrypt libgcrypt11 libgcrypt7 libgocr libnasl libsafe libtasn1 libtasn1-2 lilo lilypond linuxdoc-tools lyx magicfilter mairix make malaga mdk mgetty mifluz minc mit-scheme mlton moon-buggy mozart musixtex mysql-dfsg-4.1 numerix octave-forge octave2.0 opensched papaya pmx pspp ptex-bin python-crypto quagga r-base refblas3 roleplaying sane-backends saoimage sbcl sbm scalable-cyrfonts scummvm tcng tfm-arphic therion tor transfig u++ userv uudeview waili wmaker-usersguide xconq xfree86 xt-aterm xt-toolbus zope zope2.7 inform lgrind sgb
This is the list of packages that directly build-depend on tetex-base,
and have not yet been tried:
acl2 bibtool cweb cwebx cxref freetype1 gpsbabel musixtex mysql-dfsg-4.1 sbm zope2.7 sgb
This is the list of packages that directly build-depend on
tetex-extra, and have not yet been tried:
acl2 adolc advi aleph bibtool boot-floppies cameleon cassbeam chktex cl-tclink cmucl cxref darcs debian-zh-faq doc++ doc-debian-es dvipdfmx dvipng ecartis ecasound2.2 fpc freefem freefem3d gap-ctbllib gnuplot gprolog hyperlatex ifhp ion2 ion3 iproute jlint laptop-net libcaca libgocr libnasl libsafe libtasn1 libtasn1-2 lilypond linuxdoc-tools mairix malaga maxima mit-scheme mlton mozart musixtex mysql-dfsg-4.1 noweb numerix oaklisp opensched papaya pmx pointless psp ptex-bin python-crypto r-base roleplaying sane-backends sbm scummvm skribe tcng tor transfig u++ userv uudeview waili xt-aterm zh-sgmltools zope zope2.7 gfont
-------------------------------------------------------------------------------
Is there a chance for teTeX-3.0 in sarge?
Frank Küster <frank@debian.org>
version 0.1, 2005-02-23
Reply to: