Re: Is there a chance for teTeX-3.0 in sarge?

[Henning Makholm <henning@makholm.net>]

Scripsit Frank Küster <frank@debian.org>

> |      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.

Is debdiff really the right tool here? According to its manpage, when
it is comparing .debs it only checks whether the *names* (and
permissions) of files differ. But that will not catch, say, a manual
that tries to build itself but leaves out all of its EPS figures
because it erroneously thinks it's being output as PDF.

It seems that one ought to compare file _contents_ in order to be
sure. But then we run into problems about

1) Timestamps being embedded into the output of many build tools,
   including TeX itself.

2) Some time ago, somebody trawled through the archive, grepping for
   instances of (I think) /home/[a-z]*/debian in the contents of
   .deb's. He found that surprisingly many packages have build
   processes that embed incidental information about their build
   environment into the resulting binaries. This means that binary
   packages from the archive are probably not good baselines for
   comparisons.

3) Even disregarding this, toolchain changes since the versions in
   sid were build may well have effects that overshadow the difference
   between teTeX versions.

Here's my immediate idea about a robust test procedure:

a) Build the package in a chroot with 2.0.2 installed. Save the .debs.

b) Upgrade the chroot to 3.0. Build the package again in the same
   directory. Save the .debs. again.

c) Let time pass for a few minutes, and build the package _again_ in
   exactly the same environment as (b).

Unpack the data.tar.gz component of all .debs in temporary directories
and compare their contents. If there are byte differences between (a)
and (b) that are not close to byte differences between (b) and (c),
then flag the package for manual attention.

Of course, (c) can be omitted if there are debdiff-visible differences
between (a) and (b) or (I suppose) if there are files that differ in
more than a few dozen bytes.

Steps (a)-(c) may be interleaved between multiple packages if their
build-dependencies can coexist. This would save the work of repeatedly
installing and removing different versions of teTeX.

> The box has a flatrate, but only 100kbit/s (that's what I paid, often
> it's 120, sometimes less).

Hm, my dual-cpu desktop box at work isn't doing anything productive
when I'm not around. It has a sufficiently fat pipe to download new
Packages files faster than I can say "apt-get update". Perhaps I
should investigate how to set up a chroot there and start it building
packages.

-- 
Henning Makholm         "We cannot time-travel in this dimension. Everything
                     is arranged differently, and they use different plugs."