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 <[email protected]> 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 > > >
