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 https://deb.i2p2.de/ and
instructions are at https://geti2p.net/debian

This document is current as of release 0.9.47, 2020-08-xx.


Build-only Dependencies
-----------------------

* ant
  This is the standard java build system.

* Java JDK
  We require openjdk-8-java or higher to build.
  For 9 or higher, require the same or higher runtime, since bootclasspath
  isn't possible.

* libgmp-dev


Current Runtime Dependencies
----------------------------

* Java JRE
  We require Java 8 or higher runtime, if built with Java 8 or bootclasspath was set
  in the build. If built with 8 or higher and bootclasspath was not set,
  then require the same JRE or higher.

* 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.

* libjson-simple-java (jessie and later, trusty and later only)
  For /usr/share/java/json-simple.jar.
  In non-Debian builds we bundle the 2.x API portion of the 2.3.0 source code; it's removed in the Debian source package.
  Compatible with 2.x only; not compatible with 3.x.

* libjetty9-java
  For /usr/share/java/jetty9-*.jar.
  In non-Debian builds we bundle the jars; it's removed in the Debian source package.
  This is for Jetty 9.3.x, which is the same as 9.4.x except it's Java 8 compatible.

* libtomcat9-java
  For /usr/share/java/tomcat9-*.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.
  This is for Tomcat 9.0.x, which is what's in recent Debian/Ubuntu.
  Tomcat 8.5.x in Xenial also works.

* 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.

* libgmp10
  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.

* famfamfam-flag-png
  Country flags (all except precise)
  In non-Debian builds we bundle the flags.


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 https://github.com/maxmind/geoip-api-java
  No package or not widely available.
  There is a Maven geoip-api package at http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22com.maxmind.geoip%22

* hashcash
  One Java source file.
  From http://www.nettgryppa.com/code/
  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.
  From https://github.com/PauloMigAlmeida/identicon
  No package or not widely available.

* rrd4j (jrobin.jar)
  This is the Java graphing package.
  We bundle most of the source from https://github.com/rrd4j/rrd4j
  No package or not widely available.

* 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.
  From https://github.com/cybergarage/cybergarage-upnp
  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 https://github.com/zxing/zxing
  No package or not widely available.
  There are Maven zxing packages at http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22com.google.zxing%22


Other Issues and TODO
---------------------

* Building
  As of 0.9.28, our Debian repo at https://deb.i2p2.de 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 override.properties
  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 https://trac.i2p2.de/wiki/Crypto/ECDSA

* 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.

* AppArmor
  Needs work. In complain-only mode now.
