Hi Grant, You wrote: > I guess the debian folks are aware of this: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=518623 > > and my reading of that is that it's not a lucene dependency, but a > pylucene dependency.
Yes. The liblucene2-java package has no Python dependency, and the most recent version of that package has changed the Depends to openjdk-6-jre or java5-runtime. I don't know what the Build-Depends is. > I should also add I have no idea what happens if > you try to run pylucene against a different java runtime: The build > process seems quite intricate (IIRC it pulls down both java and lucene > source), and so I'm not sure whether it would just work. Probably > something for the pylucene list (which must be hosted by Apache now, I > guess). I've only looked at it for a few minutes, but it seems like the build process pulls down some java sources to build the jcc tool. Since there is also a separate jcc package, the pylucene package probably doesn't need any of that, either. I may do some research into the pylucene project. Andi is quite active in the pylucene-dev mailing list. But even with all of that, I'd have to contact the Debian pylucene maintainer, since he's already produced one package. (That existing package, by the way, pulled the source in January 2008, when the project was still managed by OSAF.) > In any case, I guess the Linux packaging goal would be to have > chandler depend only on pylucene. In fact, we could probably do that > today (i.e. with the existing Jaunty package) if we made chandler > depend explicitly on python 2.5. (There are a couple of scripts that > might need to be #!/usr/bin/python2.5 rather than #!/usr/bin/python). That seems the most logical way to do it. Depend on pylucene, let the pylucene package depend on the lucene package, jcc, etc., and let the lucene package depend on a Java runtime. That's after the packaging is all settled in the ideal fashion. But if the current Chandler package builds and uses the Lucene that is stored in the chandler svn repository, all of those dependencies need to be listed in that package. Otherwise, if I try to install that package tomorrow, I wouldn't have the necessary java runtime installed, if it's a fresh system. As for depending on python2.5, I'd be reluctant to do that. It may solve the dependency problem, but it would pull in another python installation. I'm not sure what the quick and dirty solution is. > On 25 Jun, 2009, at 00:41, Matt Schafer wrote: > >> 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. > > Oh, that sounds cool. I have been using minimally installed VirtualBox > instances, and hand-parsing the Build-Depends entry to install those > packages, but a tool to do it would hopefully be easier :). Check out the log of the Ubuntu package training session from last night. It's at https://wiki.ubuntu.com/Packaging/Training/Logs/2009-06-25 >> 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. > > Yes, you're right. I was originally going to crank a 1.0.4, since > there are non-Jaunty fixes that should make it out into there world, > but rolling a Jaunty 1.0.3.1 should be reasonably quick instead. I'll > do the packaging changes today, and create a 1.0.3.1 svn "tag" for > building. Let me know if there's anything I can do to help. Matt _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
