Re: Is there a chance for teTeX-3.0 in sarge?
Florent Rougon <f.rougon@free.fr> schrieb:
> Hi,
>
> You wrote a very nice analysis of the situation, thanks.
>
> I don't really know what to say as for the best course of action to
> take. While KDE and GNOME have huge deps and build-deps, their
> respective upstreams (each) more or less behave as one entity. For
> teTeX, there are many, many different upstreams. I don't know if we can
> be confident that compatibility was well-preserved for all, or most
> packages between teTeX 2 and teTeX 3. Surely, teTeX 3 has been tested
> for a long time, but does that guarantee compatibility?
Hm, I don't even think that testing of teTeX is the place where such
things would be found. In fact it focussed mainly on the compilation on
a variety of UNIX-like platforms, and on testing the function of the
changed scripts and conffiles (fmtutil(-sys), font creation stuff, much
more TEXMF trees supported). I think that incompatibilities between
packages will reveal, or have revealed, themselves on the systems of
people that update their TEXMF trees from CTAN.
Moreover, I think that if packages that used to work together without
hacks (i.e., only using documented user macros), but stopped doing so
after an upgrade of one or both,
- this would very likely have already been detected by people keeping up
with CTAN, and either fixed, or a workaround published if the
author is working slowly, and
- these packages are plain buggy, and we could apply the published
workaround.
But in fact I don't expect much of that, although not because of teTeX's
test cycles. In fact I think that such bugs either are found rather
quickly (if the packages are frequently used, and not rarely used
together), or they are found really slowly, on a hardly predictable
timescale, and it might just as well be that such incompatibilities are
still in 2.0.2.
Moreover, if we have 2.0.2 in sarge, more people will do partial
upgrades by putting new stuff from CTAN in to TEXMFLOCAL than would do
this if 3.0 is in sarge; and they would do this with more packages,
while still keeping the base from 2.0.2. I think that getting
incompatibilities introduced by such partial upgrades are more likely
than finding them in 3.0. And this would not benefit our users, nor
would it help us: We'd get seemingly valid bug reports about packages
shipped with tetex-2.0.2 only to find out that it's a incompatibility
with an other package after it has been updated.
> I mean, I
> suspect many people who test these things when they are at beta state to
> quickly adapt their documents to a new package when they find that one
> of their documents doesn't compile correctly anymore, instead of fixing
> the package so that it doesn't break compatibility.
The people that have tested teTeX-3.0, maybe; but not the ones just
downloading from CTAN. Moreover, what can "adapt their documents" mean?
Either there was a hack in them, using package internals that stopped
working - you cannot expect that to work after an upgrade. Or there's a
major flaw in the package that has been undetected as yet.
Yes, it would have been better to make such changes longer before a
release. But I think that the number of people that we gain for testing
by putting a new teTeX version into testing/unstable is hardly
significant compared to the numbers of testers who don't care about
teTeX releases (but use MikTeX, TeX-Live, or CTAN updates), and to the
numbers of people that do upgrade when sarge is frozen and/or there's
security support for it.
What I want to say with this is: In terms of finding incompatibilities
between (La)TeX packages, we don't gain much if we have a testing phase
of 1 year compared to 3 months, and I would not take this as a
particular strong argument against pushing 3.0 into sarge at this
stage.
> 1. I fear that some people who are not reading this list may be bitten
> by the upgrade, that's all.
Surely. Let them be bitten by the upgrade - then they won't be bitten if
they finally choose to use backports of 3.0 because 2.0.2 is to ancient
even for them, shortly before etch is "very near to release", you know,
somewhen in 2010 :-(
Regards, Frank
--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer
Reply to: