Submission Guidelines

The SlackBuilds.org project is maintained by a small group of people, but we want the scripts in our repository to be representative of the entire Slackware user community. There's no way that the few of us can possibly write scripts for all of the extra applications that users want to have, so we depend on YOU to help us out. If there's some application that you use, and we don't have it in our repository already, please consider writing a build script for it and submitting it to us for possible inclusion. See below for our submission requirements.

Submit scripts for possible inclusion using our SlackBuilds Upload Form, but make sure you follow the guidelines below. Do not include the source code or your upload will be rejected.

Before expending time and effort in writing a build script, be sure to search our repository to make sure one doesn't already exist. Also, you may wish to have a look at the pending queue to see if someone else has already submitted what you're planning to do. It might be a good idea to look at the ready queue as well to see what updates are going to be part of the next public update.

You will still need to read the list of requirements, but we have SlackBuild Script Templates available if you would like to download them for easy editing.

All submissions should be an archive, compressed or uncompressed - either one is fine - (tar, tar.gz, tar.bz2, or .tar.xz) of a directory (named according to the application's name) containing at least the following files:

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

$PRGNAM.SlackBuild Requirements

• Follow our template scripts as much as possible. Deviations are fine where needed, but don't change things to be "more clever" or some such - we like consistency
• You will need to note the author of the script and add licensing information. The only requirement we have is this: the license must be open-source and allow for modification and redistribution of the modified version.
  • We strongly suggest you use the BSD/MIT style license as seen in the templates.
  • If you do not specify a license then your submission might be rejected.
  • 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.
  • We do not accept "Public Domain" scripts. Public domain is not valid in some countries, and no license is worse than a "bad" license in those countries.

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 optional application and/or library dependencies that are not included in the official Slackware package set and not listed as part of REQUIRES in the .info file; 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:

• PRGNAM="(name of application)"
• VERSION="(version of application)"
• HOMEPAGE="(homepage of application)"
• DOWNLOAD="(direct download link(s) of application source tarball(s),
  arch-independent or x86)"
• MD5SUM="(md5sum(s) of the source tarball(s) defined in DOWNLOAD)"
• DOWNLOAD_x86_64="(direct download link(s) of application source tarball(s), x86_64 only)"
• MD5SUM_x86_64="(md5sum(s) of the source tarball(s) defined in DOWNLOAD_x86_64)"
• REQUIRES="(required build-time and run-time dependencies; optional dependencies at maintainer discretion)"
• MAINTAINER="(name of SlackBuild script maintainer)"
• EMAIL="(email address of maintainer)"

For example, see the following rdesktop.info file:

PRGNAM="rdesktop"
VERSION="1.4.1"
HOMEPAGE="http://rdesktop.org"
DOWNLOAD="http://downloads.sourceforge.net/rdesktop/rdesktop-1.4.1.tar.gz"
MD5SUM="78dd2bae04edf1cb9f65c29930dcc993"
DOWNLOAD_x86_64=""
MD5SUM_x86_64=""
REQUIRES=""
MAINTAINER="Robby Workman"
EMAIL="rworkman@slackbuilds.org"

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.

REQUIRES contains a space-separated list of all required build-time and run-time dependencies, each named exactly as listed on the SlackBuilds.org site. It should not contain anything that is part of Slackware itself. The content of REQUIRES should only be first level dependencies (i.e. no deps of deps).

Optional dependences should not be listed in REQUIRES - they should still be listed in the README (and preferably will list what feature the optional dependency provides). If the maintainer feels that a dependency is, while technically optional, strongly recommended enough to require it, that is generally acceptable - we'll retain veto power on that but we expect that it won't be an issue.

Listing %README% as part of REQUIRES indicates that important information about dependencies is available in the README and that the script may not function correctly, or may produce undesired results, without user intervention. This is entirely for the aid of automated tools, since users should be reading the README in the first place.

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.

If the source tarball is the same for all archs, leave DOWNLOAD_x86_64 and MD5SUM_x86_64 empty. If the application does not build on one of the supported architectures, mark it as UNSUPPORTED like this:

DOWNLOAD="UNSUPPORTED"

or

DOWNLOAD_x86_64="UNSUPPORTED"

In this case you can leave the respective MD5SUM entry empty.
If the application does not build on a clean Slackware64 system, but would if there were 32bit compatibility libraries present at build time, you can mark it as UNTESTED:

DOWNLOAD_x86_64="UNTESTED"

If an application requires multiple source downloads, you can define it like this:

DOWNLOAD="dl1 dl2 dl3"
MD5SUM="md5_of_dl1 md5_of_dl2 md5_of_dl3"

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. However, we are a bit more liberal about this than Pat is - if a patch (or set of patches) makes the packaging process easier or more efficient, we'll often include the patches.
  
  
• As a general rule, we do not accept SlackBuild scripts of software that is included as part of Slackware; however, exceptions may be made by the admin staff on a case-by-case basis.
  
  
• It's recommended to use plain ASCII for all files that are being submitted to SBo.
  
  
• We now have linting tools to test SlackBuilds and finished packages before using the submission form. Sbolint and sbopkglint can be found in the sbo-maintainer-tools SlackBuild available in the repo: sbo-maintainer-tools
  Development of these is ongoing, so it is recommended to still inspect package contents and scripts manually too, but, at the end of the day, they will save time and the frustration of rejection/resubmission.

Once you're certain that your script meets our guidelines, submit it using the SlackBuilds Upload Form.