[Xapian-devel] Debian stuff

[Richard Boulton]

Olly Betts wrote:
> As you say, it's not a perfect fit.  But I think on balance it's not
> worth changing for the moment.

Okay, I'll go with that.

I don't like the idea of making multiple tags holding exactly the same 
information.  I'd much rather simply tag the contents of the debian 
directory each time there's a debian release, and write a script to 
perform the package build which will check out the appropriate Xapian 
source, build a tarball, check out the appropriate debian control files 
and any patches, merge the tarball and the debian control files, and 
then run the debian package build process.  Once the debian build 
process has generated a source package, that can be used to build on all 
the architectures we can get access to.

One thing, though, is that I have this script which checks out the 
appropriate versions and builds all the packages that I would like to 
keep in CVS somewhere.  It's not really appropriate to place it in the 
top level directory, since most people/developers won't want to run it. 
  Any suggestions on a place to put it?

Perhaps we should have a standard place to put such maintainer scripts - 
it might be useful to keep the scripts which generate the snapshots 
there too, I suppose.


One other thing - the python build from the snapshots is failing to 
generate the "_xapian.so" library.  Instead, it seems to be generating 
"_xapian".  This looks like a problem with the version of libtool used 
to generate the snapshots.  It looks like the version is 1.5.6, or 
something like that, which I would expect to work fine.

If I regenerate "libtool" in the snapshots with libtool 1.5 (from 
/u1/james/install/bin/libtool on ixion), and rerun the build, 
"_xapian.so" gets created correctly.

The libtool generated by running configure directly from the unpacked 
snapshot has a line:

shrext_cmds='.so'

but never uses $shrext_cmds.  It does use $shrext, however.

The libtool generated using libtool 1.5 has a line:

shrext='.so'

and uses this variable later.


I'm guessing that it could be a problem due to having libtool 1.5.6 
improperly installed somewhere, such that it uses some of the support 
files for libtool 1.5 by mistake, resulting in a broken merge of the two 
libtools.

-- 
Richard