What about saving it as a lib and creating a sim-link to it named /usr/bin/saxon also?
:) ----- Original Message ----- From: "Mark Johnson" <[EMAIL PROTECTED]> To: <debian-java@lists.debian.org> Sent: Tuesday, June 26, 2001 1:53 AM Subject: java packaging questions > Hi All, > > I package some of the DocBook XML stuff and want to package some java > xslt processing tools as well, but I'm not too clear on a few policy > points. Any help/suggestions would be much appreciated. Here goes: > > 1. Package naming, libraries vs. programs, etc. > > I recently uploaded an xslt processor package, lib-saxon-java, > which follows the policy naming conventions in java-common 0.7: > > "Packages written in Java are separated in two categories: > programs and libraries. Programs are intended to be run by > end-users. Libraries are intended to help programs to run and to > be used by developers. Both must depend on > java-virtual-machine." > > [...] > > "There is no naming rules for programs, they are ordinary > programs, from the user point of view. Libraries packages must > be named lib-XXX-java." > > But saxon can be viewed as either a library or a program (if > wrapper scripts are included.) Although I did follow the naming > policy for libraries, many other packages do not. Is lib-saxon-java > an appropriate name? > > Furthermore, since I'd like to make it easy for users to do XML > processing (esp DocBook), I'd like to package some type of > wrappers. Should I do this separately? Or should I simply provide > example scripts with lib-saxon-java for use with gcj and > /usr/bin/java - type executables? > > I have similar questions for other packages I'd like to upload. The > arbortext catalog classes (and related extensions) that provide > catalog support for saxon and XT are an example. I could package > the base classes as "lib-arbortext-java", the saxon extensions as > "lib-saxcat-java" and make two more packages "xt-catalog" and > "saxon-catalog" that provide wrapper scripts. Would such a > combination be appropriate? > > > 2. Package building: Is it necessary to recompile upstream jar files? > > I hope not. :-) > > > 3. Dependencies: The java-common policy states > > "Both [libraries and programs] must depend on > java-virtual-machine." > > But many current java packages do not have this > dependency. Suggestions? > > > > Many thanks, > Mark > > -- > _____________________________________ > Mark Johnson > Duke Physics <[EMAIL PROTECTED]> > Debian SGML <[EMAIL PROTECTED]> > Home Page: <http://dulug.duke.edu/~mark/> > GPG fp: 50DF A22D 5119 3485 E9E4 89B2 BCBC B2C8 2BE2 FE81 > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > >
