-----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----- -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
