Le 10/12/2017 à 15:38, Markus Koschany a écrit :

> We usually do support this use case. Take for example the recent
> libpam4j update. No package in Debian is using it at the moment. The
> whole purpose of this piece of software is authentication with PAM and
> if you can circumvent the PAM auth mechanism, then it is obviously
> broken, in a very bad way.

IMHO patching libpam4j in the stable releases was a waste of time (and
sponsor money as far as Debian LTS is concerned) since it is totally
unused (the popcon isn't above the noise level).

> Yes, Java developers download their libraries from Maven Central and
> bundle everything. But how can you be so sure that someone is not using
> Debian libraries in production because they are stable and receive
> security support?

We can never be sure someone isn't doing something silly with our
packages, but that's not a reason for supporting them either. We already
struggle to support the latest versions of Java, if we get distracted by
fixing unused features in barely used packages we delay expected changes
in more important packages, this is also a disservice to our users.

> Why do you package libspring-java in the first place?

Because we need it as a build dependency of quite of few other packages.

> I agree we have not enough human resources to support every use case.
> But by packaging stuff we also make a promise to support packages in
> stable releases. We can't do that if we don't even know the severity of
> security issues. Then the only sensible way is to remove the software.
> Ignoring issues is and has never been a good option.

An alternative would be to mark the packages with the support level
users can expect. Something like this:
- Level 3: Full stable support. Security fixes are backported and
stability is guaranteed (for example Tomcat, OpenSSL, Linux kernel).
Feel free to depend on it for your needs.
- Level 2: Security support, stability not guaranteed. Fixes will be
provided as full updates, regressions may occur (for example OpenJDK).
- Level 1: Unsupported. The package is available as a convenience for
building other packages. Use it at your own risk. Contributions to
improve its support are kindly accepted.

> Jasperreports has lots of dependencies. My first thought was to backport
> the latest upstream release but this would probably require other
> backports.

I upgraded the package to the version 6.3.1 and it didn't require new
dependencies. Backporting it to stretch may not be that difficult.

This is the maintainer address of Debian's Java team
Please use
debian-j...@lists.debian.org for discussions and questions.

Reply via email to