[xml/sgml-pkgs] libxerces27-dev=2.7.0-1 some header files 'missing'

[Jay Berkenbilt]

Robert Barta <rho at bigpond.net.au> wrote:

> Dear packeteers,
>
> In
>
>    Format: 1.0
>    Source: xerces27
>    Version: 2.7.0-1
>    Binary: libxerces27, libxerces27-dev, libxerces27-doc
>    Maintainer: Debian XML/SGML Group <debian-xml-sgml-pkgs at lists.alioth.debian.org>
>    Architecture: any
>    Standards-Version: 3.6.2
>    Build-Depends: debhelper (>= 4.1.0), libicu34-dev, cdbs, autotools-dev
>    Uploaders: Jay Berkenbilt <qjb at debian.org>
>    Files:
>     19721059d4e9f406722350c1725d5c02 7663304 xerces27_2.7.0.orig.tar.gz
>     c476d3b35c10441097f4e18c14cb3c47 10991 xerces27_2.7.0-1.diff.gz
>
> the libxerces27-dev .deb package does not contain the files
>
>    /usr/include/xercesc/dom/impl/*.hpp
>
> because the
>
>    build-tree/xerces-c-src_2_7_0/src/xercesc/dom/impl/Makefile.in
>
> does not 'install' them. Please consider adding them by applying to that

Hello.  Sorry to take over two months to reply to your message.  I was
just going through some back email and happened to run across this.

What you are basically suggesting is that the Debian xerces27 packages
install private implementation header files from Xerces.  Although I
realize that there are some packages out there that want to include
these, I am not willing to have the debian xerces packages install
files that are not installed by the upstream maintainers.  The most
important reason for this is that those files are not officially part
of the public API and can therefore change in non-compatible ways.  If
the debian packages make those easily accessible, there is a risk that
programs compiled against them may break in ways that will cause
runtime errors when a newer version of the library is provided.
Another equally important reason is that it may make it possible for
debian users to write code that works on debian but fails to work
elsewhere with a normal xerces distribution because the user has
accidentally depended upon something that's not really supposed to be
there.

My suggestion is that you contact the upstream maintainers of xerces,
which you can find at xerces.apache.org, and bring this issue up with
them.  The xerces 3.0 release is hopefully coming soon, so hopefully
this kind of issue can be addressed before much longer.

If you are packaging something for Debian, another alternative is for
you to include the required header files in your own package, copying
from the xerces sources.  Most likely this will work fine because the
likelihood of the problem I've described actually happening is pretty
low, but at least that way, the liability from violating the public
interface would fall within your own package and not the xerces
package.  This may well be an acceptable risk for your package, but I
don't consider it an acceptable risk for the xerces packages
themselves.

Thanks for your suggestions!

-- 
Jay Berkenbilt <qjb at debian.org>