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? 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, -- 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/877gicwoxf....@bitburger.home.felix
