On 25 Jun, 2009, at 00:41, Matt Schafer wrote: > Hi Grant, > > You wrote: >> 1) Are the python --> python2.6 changes required (or recommended)? I >> ask because we use that control file to build on Hardy, Intrepid and >> Jaunty, and so there would have to be a branch in svn if the >> dependencies were different on the 3 platforms. > > Good question. You said in an earlier email that you couldn't get the > python2.5-built PyLucene to work with the python2.6 environment in > Jaunty. So I assumed that by building PyLucene in my package in the > python2.6 environment, it would not work with 2.5. I don't know if > this > is a good assumption or not.
Hi, Matt Oh, I see. Actually, I have no idea, either ... I had sort of assumed that having "python" be a Depends would pick up the default for the system (i.e. 2.5 on Hardy, Intrepid, 2.6 on Jaunty). > Since PyLucene is built as part of the package with the given debian/ > directory, the control file should list the dependencies for PyLucene, > also. I would imagine that in a proper packaging scheme, PyLucene > would > be in its own library package, it would have its dependencies, and the > chandler package would then be python2.x agnostic. At the very least > though, I do believe that the dependency should be python (<< 3.0). > The > Python folks have said that 2.x code won't work as-is in 3.0. Right. I finally became aware of the existence of the Debian Python policy manual, and I think that's what it says :). >> 2) I'm not an expert on packaging, so I'm not sure if the fakeroot >> and >> svn-buildpackage dependencies are required. They are needed for >> creating .debs, but probably there are other ways of building/ >> extracting packages? > > This is the first package I've built, and I'm just starting to read up > on how to create packages and the Debian/Ubuntu policy. So I'm far > from > an expert! > > From what I've read so far, fakeroot is needed to make a .deb in any > 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. 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. 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). 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). >> 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/. Yeah, the 8.1.0 is for Intrepid -- chandler is fine with that version (but not anything earlier). Hm, now that I think about it, Hardy had an older version, so I'm going to need to create a branch in svn anyway for 1.0.4. > 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 :). > 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. --Grant _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
