On 25 Jun, 2009, at 14:07, Matt Schafer wrote: > 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.)
At the least, I think it would be good to get that source (or newer) to build against python 2.6 (for Karmic). >> 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. I understand your reluctance :). Mostly, I was thinking it might be useful if we tried to break out all the various required subprojects into their own packages. > >> 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. Thanks; for now, I have: 1) Created an svn tag for 1.0.3.1 in the chandler repository 2) Shuffled files in around in http://svn.chandlerproject.org/sandbox/packaging/deb/chandler (essentially, to make different debian/ directories for hardy, intrepid & jaunty, because of different dependencies on python and python-twisted). Let me know if these changes look reasonable. I will do Jaunty 1.0.3.1 builds (i386 and amd64) once I have access to my box with VMs on it (probably this weekend). (I'm also interested in seeing what pbuilder is all about, but I haven't had time to look at it). --Grant _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
