[Slackbuilds-users] New slackbuild java apps submission questions
Slacker build user
slacker at slaphappygeeks.com
Mon Dec 29 06:55:12 UTC 2008
Hello list,
I have not submitted a slackbuild script before but want to submit two apps that
I use and think others would like. Both are java apps and my own slackbuild is
mostly just a repackaging of pre-built jars (ie, I do not build them from
source). To do this I find it necessary to deviate from the SBo best practices
for both and would like comments or recommendations how to handle these deviations.
The first app is ArgoUML from http://argouml.tigris.org/
UML Modeling Tool
This one is mostly straight forward except that the download archive is named
using mixed case, and unpacks to a directory structure of different case, so the
normal $PRGNAM and $VERSION vars cannot be consistently used for the unpack
operation and directory names. I am sure this is not the first one like this,
can someone point me to an acceptable solution please. For my own use I have
just hardwired the archive name in the 'tar xvzf ...' operation.
The second app is JPicEdt from http://jpicedt.sourceforge.net/
Latex PSTricks Editor
This one is distributed only in source or jar format, and we want to use the
jar. But the jar is a swing-installer which we don't really want to run, so my
current slackbuild unpacks the jar and then repackages everything necessary into
a slack package directory structure - minus the installer bits and some windows
only add-ons. But this operation requires the java JDK to be installed, instead
of the base Slackware JRE (I am using 12.1). So, while you do not have any
runtime dependencies, this creates an install-time dependency. Is this likely to
be a problem, or will simple mention in the README or slack-desc be OK?
The project is licensed GPL 2 and the installer includes a 'do you accept'
stage, but the box you are accepting is empty, so I don't think bypassing the
installer presents much problem, at least for the current version, as we include
the COPYING file. Are there any likely objections to this solution?
The last problem with this package is that it includes extensive on-line help
(that is good) but it is all hardwired into the jar executables so it needs to
remain under the same relative directory structure. Consequently, we must put
either the libs or the docs in an un-slack-like location. For my own use I have
put everything under /usr/share/jpicedt/... and have a launch script in
/usr/bin/jpicedt. Then I put copies of the quickstart, readme and COPYING under
/usr/doc/jpicedt... with the slackware README to explain it all. Any comments on
this solution?
Sorry for the length of this message, thanks in advance,
Robert
More information about the SlackBuilds-users
mailing list