No subject


Tue Apr 28 15:23:38 PDT 2009


case when you do not want to do the build as the superuser root.  So I
guess it's not strictly required.  The same probably goes for
svn-buildpackage: not strictly required, but very useful.  I just put
those in there to document all of the dependencies in one place.  Again,
I'm sure this will all be fixed up in the official packaging.

> 3) You're right about the openjdk-6-* dependencies: I guess we were  
> setting the bar lower than we thought :P.

Yeah, the versions for the openjdk-6 dependencies seemed wrong.
However, I think a bigger concern is requiring openjdk specifically.
Perhaps it's okay when building.  But there are a few different java
runtimes out there.  I personally prefer the sun-java6-jre.  Depending
on one of the virtual packages like java5-runtime or java6-runtime might
be a better choice.

I'm assuming that this is a dependency of Lucene.  (Do we need Java for
any other component?)  Lucene and PyLucene are going to be interesting.
 There is already a liblucene2-java package in Debian and Ubuntu.  I'm
guessing, but is PyLucene just a wrapper around that, exposing the Java
interface to Python?  There is also a pylucene project in Debian and
Ubuntu.  So maybe the trick is to get the maintainer of the pylucene
package to use the liblucene2-java package.  I really don't know how
this is going to work.  The dependencies that we must still build from
external/ are going to be our biggest challenge.

> 4) Yes, the version.py file doesn't pick up the svn version  
> automatically (it's tweaked by hand when creating new svn branches for  
> builds). There is currently code to figure out the version from  
> the .svn directory (if one is present); maybe there's a way to do the  
> same thing for a file installed of a debian package.

For now, I can probably just make a patch file to change version.py if I
make any more private builds of trunk.

There is a lot in that control file that should not make it back into
the repository.  As I said, I'm still at the beginning of the learning
curve.  For instance, I noticed in my build log that the version of
twisted that setuptools looks for is >= 8.1.0.  I put (>= 8.2.0) in the
Depends because that's what we have in external/.

Also, I just learned today that there is a tool called pbuilder that
creates a minimal chroot environment that has only packages marked
Essential and the build tools.  I probably should start building our
packages there to ensure that we don't have bad dependencies.

And now another question.  I noticed this evening that at least one
other person has asked in chandler-users for a Jaunty build of 1.0.3.
Should we do a 1.0.3.1 release for Jaunty, just so that folks have
something that can be run?  Right now, we have no publicly available
package for that distribution.

Matt


More information about the chandler-dev mailing list