[Slackbuilds-users] New slackbuild java apps submission questions

[Robby Workman]

On Sun, 28 Dec 2008 23:55:12 -0700
Slacker build user <slacker at slaphappygeeks.com> wrote:

> 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.


Well, let's give it a shot. :-)


> 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.


Hardcoding it is fine, especially if that's the only place you'll need
the value.  I wouldn't expect this to change at upstream, and if it
does, it wouldn't matter whether you had declared a separate variable
for it or not -- the build would still fail with a newer version.


> 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?


That's fine - just mention in the README that this requires jdk
from Slackware's /extra tree.


> 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?


No problem here.


> 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?


I'd suggest using /opt/jpicedt/ as the package prefix; then
create /usr/doc/jpicedit-$VERSION and add symlinks there to the real
docs; then create /usr/bin/jpicedt as your "wrapper" script (which I
assume will just "cd /opt/jpicedt/bin ; java jpicedt.jar" or some such.

Long story short, you had the right idea.  That's basically what I've
done with Limewire and Moneydance in our repo.


> Sorry for the length of this message, thanks in advance,


No worries - your signal-to-noise ratio was very good. :-)

-RW
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20081229/d4fafe9b/attachment.asc>