# [tex-live] hyperref/puenc.def broken after upgrade

Tue Aug 14 18:52:50 CEST 2012

On Tue, Aug 14, 2012 at 06:01:12PM +0200, Pander wrote:

>  2012-08-14 17:44, Robin Fairbairns wrote:
> > Pander <pander at users.sourceforge.net> wrote:
> >
> >> On 2012-08-14 16:48, Robin Fairbairns wrote:
> >>> Pander <pander at users.sourceforge.net> wrote:
> >>>
> >>>> About testing hyperref, the following isn't even working with xelatex:
> >>>>
> >>>> \documentclass{article}
> >>>> \usepackage{hyperref}
> >>>> \begin{document}
> >>>> \end{document}
> >>>>
> >>>> Perhaps this could be part of some automated testing in TeX Live
> >>>> whenever anything related to hyperref changes.

TeX distributions: They would have to do it for every package update
of every package. Many problems arise from compatibility issues
between packages.

hyperref: Yes, a better test infrastructure would be nice.
For some of my packages I have already some more or less
execessive tests. In case of hyperref:
* The package infrastructure is different.
* The package is much more complex, e.g., it has lots of options.
* It supports many drivers. I do not even have access to some of them
(dvipsone, dviwindo, textures, ...).
* I do not know tools that make testing in the TeX world easier
(except qstest, but that is limited to LaTeX + e-TeX).
Also tools are needed that analyze the output file formats:
* And most important the interfaces need to be clarified and more precisely
defined and even simplified if possible. Currently there are many
differences between the drivers.
* ...

Designing, implementing a reasonable test infrastructure with developing
all the needed tools is a software project much larger than hyperref itself.

Hoewever, the man power of the maintainers of hyperref is limited,
it is just one person.

> >> If hyperref is a high risk upgrade, some simple testing would be in
> >> place. People should be able to expect some quality when using TeX Live.
> >> I value TeX Live distribution a lot so some extra tests would be very
> >> welcome to keep on guaranteeing that.

Then help in writing tools that assist in automatic tests, for example.

> >> Just start out with a simple test such as the one above and each time a
> >> problem arises with new packages, just add that particular test. In this
> >> way, updating is less risky as it apparently is now.

It is on my ToDo list ...

Yours sincerely
Heiko Oberdiek