[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: