Submission Guidelines

The slamdbuilds project aims to provide SlackBuilds that are interesting and useful to the Slamd64 community. The project is run by volunteers, and so we don't have time to write SlackBuilds for every known piece of software out there. That said, we welcome submissions of SlackBuilds by others. Below are a few guidelines for the project:

We do not accept packages. This project is meant to function as similarly to SlackBuilds.org as possible, and so we are only providing build scripts. All SlackBuilds should be tested in a clean-room environment (chroot, VirtualBox, fresh install on a real box, whatever.) All dependencies should be submitted as separate SlackBuilds at or before the time of submission.

There are a few different ways to submit a build.

• The easiest for us is if you clone our git repository, and put up your own tree (on your own server, or, github for example) containing your changes - ideally, one branch per package. Once you've done this, contact us and ask us to review it for inclusion. You can get a copy of our repository with the command git clone http://builds.slamd64.com/slamd64builds.git.
• Otherwise, you can email, pastebin, ftp, or us a tarball of your SlackBuild - again, contact us with the details.

A few things to note before submitting a SlackBuild:

• Check that we don't already have the package before taking the time to write a SlackBuild. If we have one already, and you feel like it could be improved, please feel free to send a patch to the maintainer listed in the info file for that build.
• Don't include the source code. At this point, we don't have the resources to provide hosting for source code. It will need to be hosted offsite somehow. If it really becomes an issue, contact jkwood and we'll see if something can be worked out.
• All SlackBuilds must be under some form of an open-source license that allows for modification and redistribution of the modified version.
• We welcome and encourage ports of SlackBuilds originally found at slackbuilds.org with the stipulation that you do not attempt to take credit for a build you did not originally write. Any and all copyright notices should be kept, though you should feel free to add your tagline for the changes you make.

All submissions should include a minimum of four files.

• $PRGNAM.SlackBuild (for instance, rdesktop.SlackBuild)
• slack-desc
• README
• $PRGNAM.info (for example, rdesktop.info)

$PRGNAM.SlackBuild Requirements

• Use /bin/sh only - not /bin/bash or some other shell. Also, do not use any bash- or other shell-specific extensions.
  #!/bin/sh
• Clearly indicate what the script builds:
  # Slamd64 build script for torsmo

• You will need to note the author of the script and add licensing information. The only requirement we have for licensing is this: the license must be open-source and allow for modification and redistribution of the modified version.

  If you wish to license your scripts under a GPL or variant, then be sure to include a copy of the license with your submission if the license requires it. We don't encourage these licenses, as the license is often much longer than the script itself, but that's your call.

  # Written by (your name) (your contact information)
• Use variables as much as possible within your script (as opposed to hard-coding values).
  PRGNAM=torsmo VERSION=0.18 ARCH=${ARCH:-x86_64} BUILD=${BUILD:-1} TAG=${TAG:-_SB64} CWD=$(pwd) TMP=${TMP:-/tmp/SB64} PKG=$TMP/package-$PRGNAM OUTPUT=${OUTPUT:-/tmp}

  Inclusion of the _SB64 tag is a requirement.

• Make sure the following lines are present:

  if [ "$ARCH" = "x86_64" ]; then SLKCFLAGS="-O2 -fPIC" fi

  Other architectures are allowed, but x86_64 should be the primary one.

• Build in error checking where possible; for instance, the following would cause the SlackBuild script to exit if the decompress/extract operation fails:
  tar xvf $PRGNAM.$VERSION.tar.gz || exit 1
• Packages should be built with prefix of /usr, system configuration directory of /etc (except in special cases, such as /etc/$APP), library directory of /usr/lib64, and local state directory of /var.
• Strip libraries and binaries.
• Compress man pages - be sure to account for symlinks in the manpage directory if any exist.
• Compress info pages and remove the 'dir' file installed by the application.
• Leave finished package in $OUTPUT.

• For Slamd64, it's best to use a similar ARCH in the package name to the way Fred does it. The following code accomplishes that:

  DISTRO=${DISTRO:-slamd64} PKGARCH=${ARCH}_${DISTRO}

  Then, edit your makepkg line accordingly:

  /sbin/makepkg -l y -c n $OUTPUT/$PRGNAM-$VERSION-$PKGARCH-$BUILD$TAG.tgz

The slack-desc file

See the SlackWiki.org slack-desc tutorial for information on how to create a good slack-desc file.

The README file

The README file should contain at least the following information:

1. A descripton of the application. The most common way to do this is by including the contents of the slack-desc file (without the '$PRGNAM:' portion), but you may deviate from this if needed. Have a look at some of the other README files to get an idea of what is expected.
2. Any application and/or library dependencies that are not included in the official Slamd64 package set; you should also note the home page of the dependencies.
3. Any other relevant information that might be useful to someone using the script:
   • Is special configuration needed before building the package?
   • Is special configuration needed after installing the package?
   • Is this application incompatible with some other application?

The $PRGNAM.info File

The info file should contain the following information in the exact format given below:

For example, see the following rdesktop.info file:

Pay attention to the fact that all values are enclosed in double quotes; this is a requirement. Other double quotes embedded in the string are not allowed.

Note that the MD5SUM entry contains only the actual checksum rather than the full output of the md5sum command.

Note that the MAINTAINER entry is subject to change; the author of the script should be noted in the actual script itself, and while it will often (usually) be the same as the MAINTAINER, this allows a script author to turn over maintenance of the script to another individual.

Other Concerns

• No custom patches unless absolutely necessary; if at all possible, we want to maintain the Slackware philosophy of distributing "clean" stuff - if it's not in the upstream sources, then it probably doesn't need to be in our scripts.
• As a general rule, we do not accept SlackBuild scripts of software that is included as part of Slamd64; however, exceptions may be made by the admin staff on a case-by-case basis.