Xapian devel - May 2004 - xapian & debian

This is mostly for Richard, but others may have useful thoughts too.

I just took a look at the debian stuff.  It's generally looking good
(though I haven't actually tried to build the debs).  A few comments
on items in TODO:
> xapian-doc: in index.html, there is one broken link (which occurs in
> two places, pointing to the full source documentation, since we don't
> generate the full for xapian source documentation).  We could move
> this to point to the xapian website.
This isn't debian specific - it should be fixed generically.
> There should almost certainly be a link back to the front page of the
> Xapian website, too.  The documentation should also probably be in the
> style of the Xapian website, and should use the Xapian logo on the
> front page.
Another generic one.  It is annoying that the docs and bugzilla (save
the front page) don't fit in with the website style.  I couldn't see an
easy fix though...
> We don't Build-Depend on graphviz because this would mean that this
> wouldn't be able to go into the "main" archive in Debian,
because
> graphviz is non-free.
Do you need to Build-Depend on graphviz?  The xapian-core tarball
includes the documentation prebuilt.

Debian might have issues with docs which can't be rebuilt without using
non DFSG-free tools - I found some inconclusive discussion of this in
the archives of debian-devel.  Even if Debian are OK, it would be better
to not rely on non-free tools...
> To ensure we generate consistent packages whether dot is available or not,
we
> need to follow one of these possible approaches:
>  1) Ensure that "dot" isn't used when generating
documentation.  Needs new
>     configure option (note - just adding "DOT=" to configure
options doesn't
>     work).
That's sort of deliberate.  The aim is to make sure people building
tarballs build the documentation correctly and consistently.  That could
be achieved more subtlely though...
>  2) find a free replacement for dot, and build-depend on it.  (there's
one for
>     neato (springgraph), so maybe there's one for dot).
>  3) write a free replacement for dot.
Take a look at VCG (debian package vcg).  It's GPL and the closest thing
to a free replacement for dot I know of.

Moving on from TODO...

I don't think that the queryparser warrants a separate package.  It's
small compared to the main API, so splitting it off mostly adds package
overhead and potential for user confusion rather than saving much space
(for a random version I have to hand, the queryparser shared library is
78960 bytes stripped while the main library is 2710216 stripped - that's
under 3%).  Or is the split for so versioning reasons?

What's the reason for using --enable-maintainer-mode and then adding
build-depends on bison, autotools-dev, doxygen, perl5, latex, and dvips?
Is that just because of the non-free dot issue?

We should also perhaps consider providing "-dbg" package too, with a
debug
build of the library.  I'm not sure exactly what debug configuration is
most appropriate though.

Cheers,
    Olly

Olly Betts wrote:
> This is mostly for Richard, but others may have useful thoughts too.
I agree that the documentation fixes should be generic, and aren't 
debian specific - I just shoved them in TODO rather than bugzilla 
because I was in a rush, and writing the file at the time.
>>We don't Build-Depend on graphviz because this would mean that this
>>wouldn't be able to go into the "main" archive in Debian,
because
>>graphviz is non-free.
> 
> Do you need to Build-Depend on graphviz?  The xapian-core tarball
> includes the documentation prebuilt.
> 
> Debian might have issues with docs which can't be rebuilt without using
> non DFSG-free tools - I found some inconclusive discussion of this in
> the archives of debian-devel.  Even if Debian are OK, it would be better
> to not rely on non-free tools...
I'm not entirely sure of the debian policy - but I would personally feel 
happier avoiding non-free tools in the doc build anyway.
>> 2) find a free replacement for dot, and build-depend on it. 
(there's one for
>>    neato (springgraph), so maybe there's one for dot).
>> 3) write a free replacement for dot.
> 
> 
> Take a look at VCG (debian package vcg).  It's GPL and the closest
thing
> to a free replacement for dot I know of.
Hmm, looks like it would need a fair bit of work - it doesn't appear to 
read dot format, so some kind of conversion would be neccessary.
> Moving on from TODO...
> 
> I don't think that the queryparser warrants a separate package. 
It's
> small compared to the main API, so splitting it off mostly adds package
> overhead and potential for user confusion rather than saving much space
> (for a random version I have to hand, the queryparser shared library is
> 78960 bytes stripped while the main library is 2710216 stripped -
that's
> under 3%).  Or is the split for so versioning reasons?
Yes.  Debian policy says (as I read it) that you should have separate 
packages if the so versions don't change at the same time.  It's unclear
what to do it the so versions aren't the same (since the lib package 
name should end with the so version), but I think it would be reasonably 
to just choose the higher number.  If we were to decide that the version 
numbers should always change at the same time, or even better that they 
should be brought into line and always kept the same, I would make a 
single package containing the main library and the query parser.
> What's the reason for using --enable-maintainer-mode and then adding
> build-depends on bison, autotools-dev, doxygen, perl5, latex, and dvips?
> Is that just because of the non-free dot issue?
Good question.  I have been building the debian packages directly from a 
CVS checkout, which means that I don't assume the presence of any 
generated files.  This may not really be appropriate; I was assuming 
that when we next release we will tag all the CVS files appropriately, 
and I will then generate the debian packages directly from the tagged 
CVS.  This means that the tools to generate the generated files are 
neccessary.

The build depend on autotools-dev is certainly neccessary - it's debian 
policy to use this package to keep config.guess and config.sub 
up-to-date.  (See /usr/share/doc/autotools-dev/README.Debian.gz on a 
debian system)

I think using --enable-maintainer-mode is a mistake.  Will have to think 
about the other build depends you list.
> We should also perhaps consider providing "-dbg" package too,
with a debug
> build of the library.  I'm not sure exactly what debug configuration is
> most appropriate though.
I'm not sure if a debug package would really be useful, but it would be 
fairly easy to make if desired.

-- 
Richard