Files
i2p.i2p/debian-alt/doc/dependencies.txt
zzz 07dbab9f02 Util: Rename modified apache classes (Gitlab ticket #353)
to avoid conflict in applications linking to apache jars
As requested by 'mesh' project
Remove with-libhttpclient-java build option
No known external uses other than obsolete i2pcontrol plugin
2022-05-11 07:54:56 -04:00

196 lines
7.9 KiB
Plaintext

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