[lsb-discuss] libxml2 2.6.27 creates several failures in LSB libxml2 tests

[Jeff Licquia]

Here are some excerpts from the changelog for libxml2 2.6.27 (as
delivered by the Debian package with version 2.6.27.dfsg-1):

> Sun Oct 15 22:31:42 CEST 2006 Daniel Veillard <daniel at veillard.com>
> 
>         * parser.c: fix the patch for unreproductable #343000 but
>           also fix a line/column keeping error
>         * result/errors/attr1.xml.err result/errors/attr2.xml.err
>           result/errors/name.xml.err result/errors/name2.xml.err
>           result/schemas/anyAttr-processContents-err1_0_0.err
>           result/schemas/bug312957_1_0.err: affected lines in error output
>           of the regression tests

> Thu Jul 13 15:03:11 CEST 2006 Kasimier Buchcik <libxml2-cvs at cazic.net>
> 
>         * xmlsave.c: Removed the automatic generation of CDATA sections
>           for the content of the "script" and "style" elements when
>           serializing XHTML. The issue was reported by Vincent Lefevre,
>           bug #345147.
>         * result/xhtml1 result/noent/xhtml1: Adjusted regression test
>           results due to the serialization change described above.

> Mon Jun 12 13:23:11 CEST 2006 Kasimier Buchcik <libxml2-cvs at cazic.net>
> 
>         * result/pattern/namespaces: Adjusted the result of a
>           regression test, since the fix of xmlGetNodePath() revealed a
>           bug in this test result.

These changes cause the LSB 3.1 libxml2 tests to report the following
failures:

XML_0 98 FAIL
XML_1 98 FAIL
XML_11 98 FAIL
XML_2 98 FAIL
XML_29 3 FAIL
XML_4 1 FAIL
XML_4 2 FAIL
XML_4 6 FAIL
XML_4 7 FAIL

(Journal available on request.)

Any distribution shipping version 2.6.27 or later will run into these
problems.  To my knowledge, only Debian "etch" is expected to ship this
way.  IMHO, these failures should be waived.

This also brings up the issue of using exact regression results in the
libxml2 tests.  The original tests are shipped with libxml2, and are
thus tied to a specific revision of libxml2; our tests, however, have to
be flexible enough to work with many different versions.  I'm sure this
problem will come up again in the future, so it's probably a good idea
to solve it now.