Packaging solr:

Jan-Pascal van Best · External Since: Jun 05, 2007 Posts: 6

Dear all,

I'l working on packaging Solr, an enterprise search server built on
Lucene. The Solr upstream source distribution contains a number of
third-party libraries (see list at the end). I think (but I'll check) that
they are all DFSG-free. I would like to use the Debian-packaged versions
of these libraries instead of the versions included in the upstream source
package.

When I discussed this with one of the upstream developers, his reaction
was
(http://www.mail-archive.com/solr-dev@lucene.apache.org/msg04373.html):

> : > 3) Some of the jars Solr inlcudes in it's war are not
> : > the officially released version of third party software.
: > That may be a problem. For the depencies on Lucene, it
: > may mean I should either wait for the next Lucene release
: > before packaging the previous Solr release, or package
: > a development Lucene release separately (I'm also one
: > of the maintainers of the Debian Lucene package).
> It's a moving target ... the APIs may change in between
> releases (ie: SOlr could upgrade to a nightly build of
> Lucene between 2.1 and 2.2, and start taking advantage of
> API changes made after 2.1 ... those APIs can freely change
> again before the official Lucene 2.2 release. When Solr
> upgrades it's embedded version to 2.2, we'll fix any
> breakage because of those dependencies, but you may be screwed
> either way as long as you only look at official releases of
> all the parties involved.

What is the policy about this issue?

Cheers

Jan-Pascal

List of libraries in Solr:
../lib/commons-codec-1.3.jar
../lib/commons-io-1.2.jar
../lib/commons-csv-0.1-SNAPSHOT.jar
../lib/commons-fileupload-1.2.jar
../lib/servlet-api-2.4.jar
../lib/lucene-core-2007-05-20_00-04-53.jar
../lib/lucene-snowball-2007-05-20_00-04-53.jar
../lib/lucene-analyzers-2007-05-20_00-04-53.jar
../lib/lucene-highlighter-2007-05-20_00-04-53.jar
../lib/lucene-spellchecker-2007-05-20_00-04-53.jar
../lib/xpp3-1.1.3.4.O.jar
../lib/easymock.jar

--
To UNSUBSCRIBE, email to debian-java-REQUEST.DeleteThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.DeleteThis@lists.debian.org

Marcus Better · External Since: Nov 19, 2004 Posts: 393

Jan-Pascal van Best wrote:
> What is the policy about this issue?

It's generally not acceptable to duplicate code, so Debian versions of
libraries should be used.

Regards,

Marcus

--
To UNSUBSCRIBE, email to debian-java-REQUEST.RemoveThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.RemoveThis@lists.debian.org

Jan-Pascal van Best · External Since: Jun 05, 2007 Posts: 6

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?

Best regards,

Jan-Pascal

--
To UNSUBSCRIBE, email to debian-java-REQUEST.RemoveThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.RemoveThis@lists.debian.org

manfred · External Since: Feb 26, 2007 Posts: 21

Quoting Jan-Pascal van Best <janpascal.TakeThisOut@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