Re: Different Java library versions
Hi Markus,
Processing has a rather complex build system, so I've deliberately
avoided the packaging helpers and just added tasks to the upstream Ant
script, so the debian/rules file is just a simple wrapper around
build.xml. So far this has worked fine and I've got a working package;
I've been making sure it continues to obey the policies.
You say that javahelper would just create the unversioned symlink, so
does dpkg automatically handle conflicts between (say)
libprocessing3-java and libprocessing4-java if both provide
contradictory symlinks called /usr/share/java/processing-core.jar? Or
is there any action that I would need to take?
Thanks for your help,
George Bateman.
On 28 July 2016 at 16:04, Markus Koschany <apo@debian.org> wrote:
> On 28.07.2016 16:30, George Bateman wrote:
>> Hi,
>>
>> I'm packaging Processing (https://processing.org/), and I'm planning
>> to split it into three packages: processing, processing-doc, and
>> libprocessing3-java. I understand from
>>
>> that I'm supposed to create /usr/share/java/processing-core-3.1.1.jar
>> in libprocessing3-java. However, I don't understand how to satisfy the
>> line:
>>
>>> Some package must also provide a symbolic link from packagename-extraname.jar to the most compatible version of the available packagename-extraname-version.jar files.
>>
>> Clearly at the moment I could just package a symlink
>> /usr/share/java/processing-core.jar →
>> /usr/share/java/processing-core-3.1.1.jar, but what happens when I
>> package libprocessing4? How do I determine the "most compatible
>> version" of the library, and create only the correct symlink?
>>
>
> Hi,
>
> we recommend to use packaging helpers like javahelper, maven-repo-helper
> or maven-debian-helper that will do most of the work for you. For
> instance if you create a libprocessing3-java.jlibs file and edit it to
> point to your output jar file, javahelper will automatically install the
> jar and a unversioned symlink to /usr/share/java. Continue like that for
> every jar in your package. The intention is that other packages only
> need to reference the unversioned processing-core.jar to avoid upgrades
> of reverse-dependencies every time the processing-core package is
> updated. That's all.
>
> Regards,
>
> Markus
>
>
>
Reply to: