Re: libjgoodies-forms-java, was: Re: upstream + two distro packages => dependency problems
tony mancill <tmancill@debian.org> writes:
> Hi Felix,
hello Tony,
> 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.)
No Problem.
> 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.
My problem was that I have a collegue in the Freeplane project who
packages for Mageia Linux, which is still at 1.4 (so it's difficult to
patch upstream because that would break his package)... :-(
> (And 1.7.1 has been
> available upstream for over 6 months - that'll be an opportunity for a
> better transition.)
Hopefully it will go 100% smooth. 1.7.0 does remove deprecated
methods/fields (according to changelog), and I have already fixed the
deprecations in my patch.
> In any event, I will investigate the remaining rdeps (mediathekview has
> been addressed) and can help maintain the patch for freeplane if
> desired.
Thanks very much for the offer. I don't have problems with maintaining
this patch :-)
> 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.
I also don't think it's worth maintaining numerous versions, also
because it can easily be fixed. I don't think this is the case for all
packages (but I don't have much experience). However, it's important to post
here and/or mail the maintainers. In such a post, we could negotiate
whether such an additional package is really necessary.
Maybe this can be automated, like Emmanuel suggests in Thread "RFS:
guava-libraries/14.0.1-1". I think as a first step, a simple mail
announcing the upgrade and including the changelog could be mailed to
all rdep maintainers (and d-java?) ?
Best Regards,
--
Felix Natter
Reply to: