On Jun 4, 2010, at 7:57 PM, Eric Evans wrote: > >> i think the best possible solution would be for cassandra to be >> maintained as a release quality package in debian unstable, with all >> external java dependencies packaged separately and available in debian >> unstable as well, but the cassandra package itself should be prevented >> from migrating to testing and kept out of stable. > > Yup. I mentioned precisely this to Clint Byrum on IRC yesterday. > Unfortunately, I don't think there is a comparable path that would > satisfy his requirements for Ubuntu. >
Its a little more complicated than that. Really what we're most concerned with, is making sure that we direct users to a usable Cassandra solution. While having it as a source package, with all of its dependencies shipped as source packages is attractive from a long term maintenance point of view, we certainly don't want to ship something that will leave users with no upstream support in a year. MongoDB is in a similar state in Ubuntu, where the version shipped with Lucid wasn't even recommended as the version to run when Lucid released. This doesn't mean it is unusable, but it does mean the user is pretty stuck now, and upgrades at the end of the LTS cycle may be quite difficult. It seems that a better path to take would be for us to make it easier for users to find and utilize the current Cassandra packages until such time as development slows, and we can ship a version that we know will still be useful 1 - 2 years post release. So for the time being, I think we'll pass on re-packaging Cassandra, and packaging the dependencies for the impending 10.10 release, but when the effort to get Cassandra and its dependencies into debian unstable gets under way, we'll hopefully be able to throw some cycles at it. I'm particularly interested in making it easier to build debian packages / dependency information from the contents of ivy.xml, as that would reduce the amount of manual work required with each release.
