Quoting Jan-Pascal van Best <janpascal@vanbest.org>:
On Tue, June 5, 2007 16:31, Marcus Better wrote:That's what I thought, but what do we do about the 'moving target'-argument?You will have to check carefully that the dependencies are satisfied and monitor changes. Pretty much same as any other package.The difference is that solr has announced they will make use of nightly development snapshots of, especially, lucene. That means that it is possible that solr 1.2 would only compile and run against lucene-svn-20070613 or something like that (not the previous lucene-2.1, nor the upcoming lucene-2.2). It would also mean, if other projects did the same thing, that /usr/share/java would contain _several_ nightly snapshots of lucene, one for each project. If the only package ever making use of liblucene-2.2.0-svn20070613 is solr-1.2, then what is the advantage of that over having a local version of the library installed under /usr/share/solr/lib?
IMHO both approaches violate the Debian Java Policy as it stands. Technically creating a separate lucene package at least theoretically allows other packages to use it. However depending on the dependency declaration on other packages either solr breaks (if a new package includes a dependency to a newer lucene package) or the other packages might not be installable because of a version conflict or be installable but not work (becasue of incompatible API).
By having the library as part of solr in its own lib folder you at least have control and guarantee that solr will work.
One way or another the issue of allowing multiple versions of a jar in the system to satisfy the upstream package requirements keeps coming up. Going forward I think we will have to find a way to allow this and come up with a good plan for it. If we decide not to support this we will either end up with lots of packages we will create a LOT more work for us, since it is pretty common in the java world to depend on specific versions. Luckily with the classpath thats not an issue.
manfred