Re: libquartz-java v2 has incomptabilities with previous version
Le 5/5/12 1:32 PM, Andrey Ponomarenko a écrit :
> Hi,
>
> Mathieu Malaterre wrote:
>> Andrey ,
>>
>> On Thu, Apr 26, 2012 at 11:05 AM, Andrey Ponomarenko
>> <aponomarenko@rosalab.ru> wrote:
>> ...
>>> See http://upstream-tracker.org/java/versions/quartz.html
>> Ok, then. I need a little training here. How can one parse this beasty
>> table to deduce:
>>
>> - updating 1.6.6 to 1.7.3 is ok (see past uploads)
>> - updating 1.7.3 to 2.1.4 is not ok
>
> The source compatibility (ability to rebuild dependent clients) of
> 1.6.6 and 1.7.3 is estimated as 81.3% in the table. But compatibility
> of 1.7.3 and 2.1.4 is 86.6%*63.5%*79.2%=43.5% that is half as much as
> for 1.6.6 and 1.7.3.
>
> In any case, if you see any compatibility problems in the table, then
> you should try to rebuild and adapt (if needed) all dependent clients
> before update, as they may be affected.
>
> All dependent packages can be listed by the command: apt-cache
> rdepends libquartz-java
>
> Also, there is a policy for Debian Java libraries [1]. But it doesn't
> explain how to update libraries and when to bump a version number in
> libXXX[version]-java. Is there other documents for Java package
> maintainers in Debian?
>
Independently of Java, it is related to Debian libraries management. The
Debian policy on libraries [0], 8.1 paragraph, referring as examples to
SO files, specifies that a different SONAME and binary package name
should be used in case of API breakage.
SO and Java jars have same behavior.
[0] http://www.debian.org/doc/debian-policy/ch-sharedlibs.html
Olivier
> [1] Debian policy for Java: 2.3. Java libraries
> <http://www.debian.org/doc/packaging-manuals/java-policy/x104.html>
>
>>
>> Thanks much
>>
>> -M
>>
>>
>
>
> --
> gpg key id: 4096R/326D8438 (keyring.debian.org)
> Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Reply to: