[Xapian-devel] xapian & debian

[Richard Boulton]

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