"olivier.sal...@codeless.fr" <olivier.sal...@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
> [0] http://www.debian.org/doc/debian-policy/ch-sharedlibs.html
>
> Olivier
>
> Shouldn't I get a warning (notification of all reverse dependencies) or
> a post on debian-java if an incompatible update will be uploaded?
>
> I guess that such incompatible updates are only common in the early
> development phase and not so much when move towards stable?
>
> [1]
> http://freeplane.sourceforge.net/wiki/index.php/Dependencies_and_Linux_Packaging#Dependencies
> [2] I am not the only one with this, see #706925.
>
> Thanks and Best Regards,
>
> --
> gpg key id: 4096R/326D8438 (keyring.debian.org)
> Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
>
--
Felix Natter
--
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87txldlpp3.fsf...@bitburger.home.felix
