[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