On 06/04/2013 11:02 AM, Felix Natter wrote: > "olivier.sallou@codeless.fr" <olivier.sallou@codeless.fr> writes: > >> On 06/02/2013 04:46 PM, Felix Natter wrote: >> >> hi, >> >> Freeplane depends on a number of libraries [1], and I guess the usual >> process for updating the package in case of an incompatible library >> upgrade, is to fix it upstream and include a patch until the package >> is updated to this upstream version. >> >> However, problems arise if there are packages for more than distro for >> upstream. e.g. Freeplane has packages for Debian and Mageia Linux and >> libjgoodies-forms-java has version 1.6 in Debian and version 1.4 in >> Mageia. >> Since it's difficult for my colleague to update the jgoodies-forms >> package in Mageia, I am currently maintaining my own patch for 1.6 >> indefinitely... >> >> libjgoodies-forms-java is probably a tough case [2]: deprecations are >> quickly removed and i.e. classes are renamed so that you can't support >> 1.4 and 1.6 in one codebase (unless you ship parts of jgoodies-forms in >> your package). (I was lucky with libcommons-io-java because Freeplane >> already uses 2.4) >> >> => is there a better approach to what I'm doing, i.e. fix upgrades >> quickly by adding patches and then arguing with my colleague about >> whether the patch can be applied upstream? >> >> => Under what conditions is the package renamed >> (i.e. "libjgoodies16-forms-java") if there are incompatible changes? >> Could you point me to the policy requirements? >> >> Hi, >> library should be renamed what there is an API breakage. > > In theory yes, but I think this would mean that we have around 5 > libjgoodies-forms-java packages... > >> In policy this refers to section 8.1 [0] for shared libraries. Though talk is more about C shared >> libraries, same kind of policy must be applied to Java libs, being also shared libraries. >> >> Perhaps in your case, a specific libjgoodies14-forms-java should be kept. >> >> Difficulty is to know that upstream API is broken if not specifically >> documented in changelog file. > > In the case of libjgoodies-forms-java this is clearly stated in the > RELEASE-NOTES: > > CHANGES IN 1.6.0 ----------------------------------------------------- > > This version is binary incompatible with previous releases. > The vast majority of client code isn't affected, because primarily > internal interfaces and their implementations have changed. > However, some changes may require a migration, for example > if you have used the deprecated ButtonBarFactory in the past. > [...] > o Renamed FormFactory to FormSpecs. > [...] > > => the main problem is that jgoodies is written such that it is > impossible to support both 1.4 and 1.6 with one codebase :-( > > But I think it would be good to notify the reverse dependencies (or post > here) before uploading incompatible upgrades. Then we could negotiate > whether a compatibility package is necessary? > > What do you think? > > Thanks and Best Regards, > Felix Hi Felix, Yes, I agree that this is a good example of a transition that could have been handled better. It was my mistake not to verify all of the rdeps before transitioning jgoodies-forms from experimental to unstable. (I was in too much of a hurry to get jabref updated.) I'm not sure I understand the references to version 1.4, which was never part of Debian according to either the package changelog or the PTS (http://packages.qa.debian.org/libj/libjgoodies-forms-java.html). Prior to 1.6 there was only 1.3 available in Debian. (And 1.7.1 has been available upstream for over 6 months - that'll be an opportunity for a better transition.) In any event, I will investigate the remaining rdeps (mediathekview has been addressed) and can help maintain the patch for freeplane if desired. The larger issue/question about maintaining multiple versions of Java libraries remains. My instinct is that for jgoodies-forms, it is best to move forward (that is port rdeps) when possible instead of supporting the numerous versions out there. Obviously this strategy won't work for all libraries, but I think it's preferable when feasible. The alternative is serious archive bloat and cruft. Regards, tony
Attachment:
signature.asc
Description: OpenPGP digital signature