Fetching contributors…
Cannot retrieve contributors at this time
184 lines (146 sloc) 7.7 KB
This document is for Debian package maintainers.
It contains an overview of current package dependencies,
the plan for improvement, and other notes.
These notes will also be helpful for non-Debian package maintainers.
We are not packaging experts, but we are doing the best we can to
improve our official packages and support other packagers.
Our packages are available at and
instructions are at
This document is current as of release 0.9.33, scheduled 2018-01
Build-only Dependencies
* ant
This is the standard java build system.
Current Runtime Dependencies
* Java JDK/JRE
We require openjdk-7-java to build, and any Java 7, 8, or 9 runtime to run.
Java 9 may still have some issues; see for status
* geoip-database
In non-Debian builds we bundle our own geoip data;
for Debian builds we use the system data.
* gettext-base
For /usr/share/java/libintl.jar.
In non-Debian builds we bundle the source code; it's removed in the Debian source package.
* libgetopt-java
For /usr/share/java/gnu-getopt.jar.
In non-Debian builds we bundle the source code; it's removed in the Debian source package.
* libjetty9-java
For /usr/share/java/jetty9-*.jar.
In non-Debian builds we bundle the jars; it's removed in the Debian source package.
* libtomcat8-java
For /usr/share/java/tomcat8-*.jar.
In non-Debian builds we bundle the jars as packaged in the Jetty 9.2 binary release,
which are different than the way they are packaged for Debian.
They are removed in the Debian source package.
* libtaglibs-standard-*-java (stretch and later, artful and later only)
Provides JSTL 1.2, solves the glassfish-javaee problem described below.
* glassfish-javaee (wheezy, jessie, xenial and earlier only)
We need jstl.jar and standard.jar version 1.2.
This is an ancient and terrible package, but it's the only place we've found version 1.2 jars.
standard.jar classes are inside /usr/share/java/glassfish-appserv-jstl.jar
jstl.jar classes are inside /usr/share/java/glassfish-javaee.jar but we can't use it
because there are too many conflicting, old, unrelated classes in there, so we currently
bundle jstl.jar even in Debian builds.
We've found some other packages that contain version 1.1 jars:
libjakarta-taglibs-standard-java (containing standard.jar only)
and libjstl1.1-java (containing jstl.jar only).
Jetty 9 does contain JSTL 1.2 ??? but not in packages???
It's not clear why there isn't a libjstl1.2-java package.
It also isn't clear why we upgraded to 1.2 years ago, but the rest of the world didn't.
And it isn't clear why 1.1 won't work for us.
* service-wrapper
In non-Debian builds we bundle the jars; it's removed in the Debian source package.
For some Debian and Ubuntu releases, these seem to be much older than what we're bundling,
but there's no particular version that we need.
* libgmp-dev
In non-Debian builds we bundle compiled C code; in the Debian packages we have a small
C shim that links to the libgmp .so file.
We depend on libgmp-dev for both the build and the runtime, but perhaps only the
libgmp10 package is required for runtime? To be researched.
Bundled code, NOT current dependencies
These are packages that we at least partially bundle jars or java source for,
even in Debian builds. For most of these we could remove the code and add
a dependency if the package were widely available.
We have not created private packages for any of these, we just bundle
the binaries or sources.
* geoip-java
Java interface to access geoip data.
We bundle source from
No package or not widely available.
There is a Maven geoip-api package at
* hashcash
One Java source file.
No package or not widely available.
We don't really use this code anyway, but it would break compilation if we took it out.
* identicon
Small number of Java source files, modified.
No package or not widely available.
* jrobin
This is the Java graphing package.
We bundle a large portion of the 1.6.0 source from
No package or not widely available.
There is an old 1.5.9 Maven jrobin package at
Jrobin is in Gentoo.
* libhttpclient-java
We only use a few classes from this large package.
We require 4.4 or higher which is not available in older distributions.
This is 2 MB of dependencies, instead we bundle 20 KB of copied source.
If we do add this dependency, we use only the code in
/usr/share/java/httpclient.jar and /usr/share/java/httpcore.jar.
* UPnP (cybergarage)
Large subsystem, large number of Java source files, modified with several fixes.
No package or not widely available.
There is a competing UPnP library (libupnp-java) that is packaged, but it would be
a huge effort on our part to port our code to use that library instead.
Maybe we will do this some day, but it won't be soon.
* zxing
This is the QR/barcode library from Google.
We bundle a portion of the source from
No package or not widely available.
There are Maven zxing packages at
Other Issues and TODO
* Building
As of 0.9.28, our Debian repo at just contains
binaries copied from Launchpad. It's much easier than building them
ourselves, but it leaves non-x86 architectures out of date.
The directory above (debian-alt) contains various changes for different distros.
* Configuration
So that we may easily support dependency changes in various distributions,
and test alternatives, we output configuration settings to the
file in the rules script. There are extensive comments in the
rules, i2p-router.install, and i2p-router.links files.
There's probably a better or more-standard way to do this, but this makes it
easier for us, and for non-Debian packagers, if there are any.
* i2p-doc
This is just javadocs.
Added priority of 'extra' for 0.9.29, before that, everybody was installing it?
* Init/systemd
Kytv did the systemd and init script parts, no idea if it's compliant,
needs review.
* JCA issues.
This has never been a problem for Debian/Ubuntu, but many Gentoo, Redhat, and Fedora
distributions are missing or have broken ECDSA support in the Java Cryptography subsystem.
The console sidebar will show a warning and the router will log warnings if
ECDSA is not working. The router will still work, but the user will not be able
to access newer hidden services on the network. For best results, packagers
should ensure that the JCA supports ECDSA.
For further info, see
* Raspberry Pi
The performance of OpenJDK 8 on the raspberry pi is terrible, it's almost
unusable. The Oracle JDK is several times faster. But there's no package for that.
We tell people to use Oracle for ARM on our download page, but there's no
solution for package users.
* Splitting packages further
Might be nice to further split up the i2p-router package into just the
core headless router and the routerconsole/UI part.
Or even the susimail/susidns/i2psnark/i2ptunnel webapps also.
* Plugins
We don't have a strategy for building, installing, or finding packages for
3rd-party plugins using our plugin system. If we do that, then we can
have packages for popular plugins such as i2p-bote.