[Slackbuilds-users] New slackbuild java apps submission questions
rworkman at slackbuilds.org
Mon Dec 29 07:21:14 UTC 2008
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. :-)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 197 bytes
Desc: not available
More information about the SlackBuilds-users