Bug#592181: sat4j: Possibly breaks eclipse-platform without declaring it
Package: sat4j
Version: 2.2.0-2
Severity: serious
Hi Michael Tautschnig, Release people and Java people.
In light of #587657, I have decided to file an RC bug against sat4j to prevent
it from migrating to testing and quite possibly breaking eclipse-platform in
testing.
I strongly suspect that eclipse is quite frankly unable to deal with OSGi bundles
(jar files with OSGi metadata in their manifests) changing their "Bundle-Version"
entry if they are listed in the bundles.info file that eclipse uses to register
some of these bundles (sat4j being one of them).
#587657 started out being a problem with jetty (that bumped its version in a
recent upload) for some users; after jetty migrated to testing it was silent
for a short while. Shortly after the sat4j upload we got a new report of
eclipse acting up and sat4j appears to have changed its Bundle-Version in the
2.2.0-2 version currently available in unstable.
I am currently having the person test if reverting sat4j to the 2.2.0-1 in
testing (and correcting the bundles.info which gets messed up) solves the
issue. I will get back to you when I have more information on that.
If my speculation turns out to be true, then we have a general issue with eclipse
that needs to be solved. It is simply too error-prone to rely on maintainers to
remember to bump their "Breaks: eclipse-$part ($version)" every time they update
their package and have us to a Source upload to bump (Build-)Depends.
"Luckily" most of the Java Team maintained packages have the OSGi metadata
hard-cored and will have to be updated manually, so at the current time these
packages should not break eclipse (provided people just leave it alone for
now).
I suspect we can solve this by using file-triggers and a script to manually update
bundles.info, but it is not something I can promise to get done and have well testing
for Squeeze, so I would much rather just do one more upload of eclipse 3.5.2, bumping
the (Build-)Depends for Squeeze and then work on this script for Squeeze + 1.
Obviously I would need a freeze exception for eclipse and I will file that
separated when we have verified the issue and prepared the issue.
I would like to apologize in advance if my assertions turn out to be incorrect and
the issue turn out to be unrelated to sat4j and eclipse. I decided to take the "rather
safe than sorry" approach to possibly breaking eclipse in testing. As I am returning
from DebConf10 tomorrow, I may be slow to reply in the next few days.
~Niels
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.32-trunk-686 (SMP w/2 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages sat4j depends on:
ii default-jre [java6-runtime] 1.6-38 Standard Java or Java compatible R
ii jarwrapper 0.31 Run executable Java .jar files
ii openjdk-6-jre [java6-runtim 6b18-1.8.1-1 OpenJDK Java runtime, using Hotspo
ii sun-java6-jre [java6-runtim 6.20-dlj-4 Sun Java(TM) Runtime Environment (
sat4j recommends no packages.
sat4j suggests no packages.
-- no debconf information
Reply to: