Making a repository

Starting with version 0.2.0, smc-get will be able to process XZ-compressed tarballs as so-called “packages”. These packages can be organized into a repository from which the program can download new packages and look into for new versions.

With the final release of 0.2.0, smc-get will have an official repository that is included in smc-get’s configuration by default. You can roll your own repo and use that one instead of the official one, but note we do not support such user-created repositories.

Beta notice

This article refers to a not-yet released version of smc-get. It may contain incorrect information as development of smc-get goes on.

Building a repository

0. Prerequisites

You’ll need Ruby in version 1.9.2 and the smc-get and adsf gems. You should already be familiar with the former one (otherwise you wouldn’t read this), the latter one is a handy tool for firing up a small webserver in any directory of your filesystem. Note that adsf servers are not suitable for placing your repository publicely on the Internet — for that, use more robust weservers such as the well-known Apache Web Server. I just use adsf here for demonstration as it’s really easy to use.

# gem install smc-get adsf

1. Build your packages

After everything has been set up, you should choose the files you want to package. SMCPAK files can contain levels, graphics, music, sound effects and even worlds, but remember that the more you choose to include in your packages, the bigger they grow. If you find yourself always distributing a certain set of graphics with all your packages, you should probably put these graphics into a separate packages and declare it as a dependency of all your other packages. This also keeps the users’ local installations clean.

Now invoke the command:

$ smc-get build

smc-get will query you for all necessary things it needs to know about your package, e.g. what levels to package, how to name the package, the author’s name, etc. If you read the descriptions output by the command carefully and gave correct answers, you’ll end up with a file called something like yourpackage.smcpak in the current directory. This is a distribute-ready package you could email others. However, to always email big packages is a bit inconvenient. And this is the moment where you can think about an own repository for your packages.

Build as many packages as you want to have in your repository. You can also compeletely automize the process of building packages if you provide smc-get build with a directory name containing all necessary files. See smc-get help build for further information on this.

2. Create the directory structure for a repository

smc-get expects a repository to be structured like this:

/
  - packages.lst [FILE]
  /packages      [DIR]
  /specs         [DIR]

Create these directories and an empty packages.lst file which you can then fill with the names of the packages your repository contains. If you e.g. have the packages awesome.smcpak and mypackage.smcpak, your packages.lst would look like this:

awesome
mypackage

It’s just an ordinary text file containing the packages’ names without the .smcpak file extension, one per line.

3. Copy the packages

Copy your package files (i.e. those ending in .smcpak to the packages/ subdirectory.

4. Extract the package specs

smc-get doesn’t want to download the whole package just because a user wanted to find a package containing a certain level. For this task, it just downloads the package’s specification. As you might have guessed, this is where the specs/ subdirectory is for: It contains your packages’ package specifications.

You now have to extract the SMCPAK files (at least they’re just XZ-compressed tarballs) and copy the file <pkgname>.yml inside the resulting directory into the repository’s specs/ directory. For example, if you have the package awesome.smcpak, you’d do this:

$ cd /yourrepository/packages
$ mv awesome.smcpak awesome.tar.xz
$ tar -xJf awesome.tar.xz
$ mv awesome.tar.xz awesome.smcpak
$ cp awesome/awesome.yml ../../specs
$ rm -r awesome

In case you wonder why I have to rename the file to a .tar.xz extension: The xz commandline program which is utilized by tar when passing the -J switch refuses to extract compressed files with another extension than .xz. After extraction you can safely re-rename the file to it’s old name with the .smcpak extension.

5. Start the server

That’s it! You’ve now got a complete SMC package repository. Point your web server at the repository’s root directory and tell smc-get via one of it’s configuration files (see smc-get help) about your repository’s URL and you can use the repository. As an example, I put this into my ~/.smc-get-conf.yml:

repo_url: "http://localhost:3000"

and now I do (inside the repository’s root directory):

$ adsf -p 3000

In another terminal, do

# smc-get install awesome

Finished!