eclipse in Squeeze (again)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi
I had a chat with Julien Cristau about some of this in #debian-release;
so some of you may already know this. eclipse 3.5.2-6 which migrated to
testing not long ago is built against and implicitly depends on the
lucene2 from unstable. Unfortunately I failed to notice this when I
found the sat4j-eclipse issue[0].
This is "trivially" fixable by doing a rebuilt of eclipse-platform in a
testing environment on all archs, so doing a testing upload is possible.
Nevertheless any further update to eclipse targeting Squeeze would have
to be done via testing uploads as well then[1].
The alternative is to accept lucene2 from unstable into testing; this
would also fix the issue. I would suggest we do a minimal upload of
lucene2 and eclipse then to prevent unsafe upgrade paths (adding a
Breaks and bumping versioned Depends respectively)
Finally there is possibility to "downgrade" lucene2 in unstable to match
the version in Squeeze.
Personally I am fine with either of the 3 options; admittedly I am not
an uploader of lucene2 so if we are going with the third option we
should involve the active lucene2 uploaders. On a related note, Julien
Cristau had a/considered to have a look at the lucene2 diff, but I have
not heard his verdict on it yet.
Now that we are done with the "good news"... Even once we have solved
the problem above, eclipse is likely unable to fix itself for upgrading
users. As I understand this problem, it is caused by /any/ upgrade
that changes which java libraries eclipse was built against.
The problem "only" affects people who needs eclipse plugins beyond
those provided by the eclipse source package. These plugins can be
resolved by a more robust dependency solver.
We ship a "bundles.info" file in eclipse-platform which lists all the
plugins built from the eclipse source package and their dependencies.
When eclipse is started for the first time it will copy the contents of
this file to a user bundles.info. If the user install new plugins they
will be listed in the user bundles.info.
The problem is when we bump a core plugin or one of their dependencies
(e.g. lucene2 or sat4j); the system bundles.info will be upgraded
correctly, but eclipse fails to merge these changes into the user
version of the bundles.info.
Honestly I thought eclipse was able to do this for us though I might
have confused "actual features" with "planned features" here.
Nevertheless we can work around this issue in at least either of 2 ways:
* Have the user purge ~/.eclipse.
+ eclipse will reinitialize bundles.info correctly.
- user will have to reinstall all user installed plugins.
* Write a script that attempts to merge these files.
+ upgrades will be smoother for a lot of our users.
- introduces a new point of failure.
Note it is likely that we will have similar problem when the user
upgrades eclipse upstream version (see #352197).
Regardless of the option we choose I intend to write a NEWS item for
eclipse so that people becomes aware of the issue; what the symptoms are
and what the possible solutions to the problem are.
~Niels
Note: Please CC me in replies.
[0] #592181
[1] Hopefully there will be no more changes!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEAREIAAYFAkyCEaIACgkQVCqoiq1YlqwOxACffCQTcEGBnaC6yjPsRq5KgxDI
KbgAoNUwEmxlR4eu4Q+0ZJbgwms5Oymm
=znD4
-----END PGP SIGNATURE-----
Reply to: