Quoting Jan-Pascal van Best <[EMAIL PROTECTED]>:
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
