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.38, 2018-01-xx. Build-only Dependencies ----------------------- * ant This is the standard java build system. * Java JDK We require openjdk-7-java or higher to build. For 8, set bootclasspath to java 7 jars if available. 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 7 or higher runtime, if built with Java 7 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 1.1.1 source code; it's removed in the Debian source package. Compatible with 1.x and 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.2.x, which is what's in Debian. We are not compatible with Jetty 9.4.x, which is what's in RedHat. * 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. This is for Tomcat 8.5.x, which is what's in recent Debian/Ubuntu. Tomcat 8.0.x in older Debian/Ubuntu may or may not work. * 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 precise and 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. * jrobin This is the Java graphing package. We bundle a large portion of the 1.6.0 source from https://github.com/OpenNMS/jrobin No package or not widely available. There is an old 1.5.9 Maven jrobin package at http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.jrobin%22 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. 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.