Hi,
> > If you're already testing your packages at all currently, it's not
> > too much overhead.
> >
> > If you aren't running any tests, well that probably tells something
> > about the current quality of your packages.
>
> I am running all my packages on my own system for at least several days
> and sdo many tex file runs, either trough regular work or through
> recompiling old files.
>
> But still I would like to have an automated test-bed.
That's great, but I expect that it's cumbersome unless you have got it scripted.
And I believe it's still cumbersome to test install/uninstall of scripts.
Currently my workflow with pbuilder and most packages is that I do an equivalent of
pdebuild --hookdir /the/location/to/hookdir --buildresult ~/pending/TODAY/
where the hookdir contains '/usr/share/doc/pbuilder/examples/B92test-pkg'.
This will build the package inside the chroot, install the package,
and run debian/pbuilder-test/* scripts inside the chroot, and only
copy the resulting deb file if all the shell scripts return '0'. This
might be a not-too-invasive addition to your package build-flow, I
don't know.
One thing that I am worried, from my perspective is that i18n isn't
too tested, because it's often not obvious how to run tex files of
languages other than your own.
Just having a chrooted pbuilder job re-running the makefiles for a
free document[1], and making sure there is zero 'cvs diff' output for
every PDF file might in fact help. I'd try and go and script some
pbuilder script to run that.
One important thing aspect of testsuites is that it should be trivial
to run, or automated, so that it won't impose too much overhead on the
developers. Otherwise, IMO, it would be just too much load.
> An no, I am *NOT* testing each and every program in my texlive packages,
> but I guess none of the tetex developers is doing it neither!
That I guess so. Unlike CPAN, which seems to be mandatory to have a
testsuite, tex doesn't seem to have such thing. Technically it might
be doable, but I doubt if it can be ran in a reasonable time in terms
of amount of work preparing it, and the amount of time required to run
through.
What I had in mind was having some kind of an example tex file of what
could be considered a typical usage, and re-run tex over it, producing
dvi/ps/pdf. That way, we at least know they do compile, and if we can
check the diffs, that might be a good way to catch any changes.
/me checks, and rebuilding twice with dvipdfmx seems to obtain two
different results... Apparently they have BaseName, FontName, CMapName
directives different every time.
@@ -751,7 +751,7 @@
/CIDInit /ProcSet findresource begin
12 dict begin
begincmap
-/CMapName /RXGTTZ+CMR17-UTF16 def
+/CMapName /WEUQPZ+CMR17-UTF16 def
/CMapType 2 def
/CIDSystemInfo <<
/Registry (Adobe)
[1] http://cvs.alioth.debian.org/cgi-bin/cvsweb.cgi/monthly-report/?cvsroot=tokyodebian
regards,
junichi
--
dancer@{debian.org,netfort.gr.jp} Debian Project