dblatex uses a lot of embedded copies of software that already
is part of Debian. This should be changed in the long run.

E.g. imagine a security bug is found in rubber and the Debian
security team updates rubber, but not the modified grubber in
dblatex nor twenty more packages embedding copies.

Other example: l10n files from docbook-xsl. The latter already
has support for Esperanto, Latvian, and Norwegian Bokmål.
dblatex could just depend on docbook-xsl and use its files.

This needs certainly cooperation with upstream(s).

IIRC, dblatex contains a copy of rubber, which is a Debian
package as well. I think dblatex contains some changes/fixes,
which probably can be incorporated into rubber directly.

W. Martin Borgert <debacle@debian.org> wrote:

Hello Martin and Benoît,

Martin, thanks for your reminder regarding this report.  I always
thought I had answered this already, only to learn now that I never have
actually sent the draft…  Sorry.  Anyway, better later than never:

I agree with you in general: for a software distribution like Debian it
is achievable to reuse existings components instead of copying them.
However I also respect the upstream goal to introduce as few
dependencies as possible, even now the list is quite long for someone
installing manually (quoting the documentation regarding dblatex's
dependencies):

- An XSLT processor
- The XML DocBook DTD
- A recent LaTeX distribution
- Python >= 2.4

Let's look at the two embedded dependencies mentioned:

rubber → grubber
----------------

I have tried to compare the grubber with the rubber files, and it looks
like grubber has been modified substantially, even the file names don't
match any longer.  But the expert for this surely is you, Benoît, as
grubber's creator.  The question is about the nature of grubber: is it
an adaption that can be reintegrated back or is it a meanwhile
independant fork?  Anyhow – at least two issues must be resolved in
order to use rubber with dblatex:

- rubber would need to expose its functionality as a Python library, at
  the moment its only interface is the command line.

- rubber would need to support XeTeX.

l10n files
----------

It's quite easy to use the original l10n files of docbook-xsl instead of
the dblatex ones: just change the link to l10n.xml in
/usr/share/xml/docbook/stylesheet/dblatex/xsl/common/l10n.xsl from the
dblatex to the docbook-xsl location.  The result works basically, but
when executing a more complex document like the dblatex documentation
one observes warnings like:

No context named "xref-without-title" exists in the "en" localization.

This demonstrates that the dblatex files have been adapted, too.  As I
can't imagine docbook-xsl to integrate dblatex specific adaptions, a
strategy would be to separate the original files xyz.xml from the
dblatex adaptions xyz.dblatex.xml.  With this restructuring dblatex
would load the xyz.xml files first and the xyz.dblatex.xml files
afterwards.  For upstream dblatex the xyz.xml files would be kept in the
dblatex package, whereas Debian dblatex would remove them and use the
docbook-xsl files instead.

Benoît, as usual the original report can be found at:
http://bugs.debian.org/492736

Curious about your thoughts, Andreas

Hi,

Thanks Andreas for your analysis. My point of view about the mentionned
dependencies:

- grubber was adapted from rubber to fix some bugs or limitations i
encountered, and to have an interface i could work with. I think it would
not be that easy to to put changes back in the mainstream, and on the
contrary keeping grubber close to the dblatex needs ensures dblatex an
easy maintenance. For me, it is not worth trying to do something.

- the l10n files were a moving target when i first used them (it was the
beginning of the overall translation mechanism) so that it was easier to
embed them to ensure stability. Now it is quite stable and dblatex mostly
uses the same features. The xref-without-title template could be easily
removed. The only significant (but few) changes are about some common XSL
files to make it work in any case in latex. So, the original l10n XML
files could be used, used by the dblatex common XSL files.

Before trying to work on the second point there are many open tickets to
fix (since it's a very long time I haven't looked at dblatex), so it can
take a while.

Regards,
BG