Slackhammer Project

Last updated 2017-05-09

What is Slackhammer?
What is a Slackhammer "source archive"?
What is a Slackhammer "binary archive"?
What is a Slackhammer "metarepo"?
What is a Slackhammer "instance"?
What are some Slackhammer use cases?
What is the status of Slackhammer?
What is Slackhammer?
Slackhammer is a framework for managing, modifying, testing and releasing Slackware-like Linux distributions.
Each Slackhammer instance would represent the state of a Slackware-like distribution, and could be updated either from an external source (such as the official slackware-current install set) or manually, or reverted to an earlier state.
Via Slackhammer's cli tools, commands will be available for (at least):
  • Building binary packages via .SlackBuild script,
  • Running tests (unit, integration, system),
  • Updating / reverting packages,
  • Linking to bug reports and CVEs,
  • Generating reports,
  • Exporting an installation-set.
The current design divides the framework into four subsystems, to facilitate co-operation and avoid undue duplication of data:
  • An "instance", representing the state of a distribution,
  • A "metarepo", tracking information about packages,
  • A "source archive", storing source tarballs.
  • A "binary archive", storing installation tarballs.
This division allows several instances to all use the same metarepo and source archive, for instance, or different metarepos and the same source archive, or different metarepos and source archives, etc.  Metarepos and source archives can be remote.
The current plan is to make instances and metarepos git repos and source archives simple file directory hierarchies.  They are described below in bottom-up order to make the relationships between them easier to understand. 
Idlemoor's SlackRepo will be leveraged to provide the build and test functionality.

What is a Slackhammer "source archive"?
A Slackhammer source archive is simply a filesystem directory containing one subdirectory per package component being tracked by the system.
Each subdirectory contains a file (a tarball, zip archive or similar) for each version of the component being tracked, containing the component's source code.
Most packages only contain one component, so there would be a one-to-one relationship between packages and components.  The "gpm" package, for instance, only has one source tarball, so versions of the gpm source tarball would be stored under the "gpm" subdirectory.  The "infozip" package, on the other hand, requires tarballs for "zip" and "unzip", which would be stored in their own subdirectories.
Slackhammer would include a "slackhammer-archiver" utility which looked for new releases of these source archives, checked their checksums, and added them to the source archive, as best it could.  Not all package upstreams are well-disposed to automatic harvesting.
I anticipate providing public access to my own source archive online, for a few reasons:
  • This is the most data-intensive component of Slackhammer, and not everyone has the disk or bandwidth to spare for provisioning their own,
  • Several upstream providers only provide access to the latest version of their sources, so a central archive would provide access to older versions of those sources,
  • Sometimes upstream providers lose their hosting, and a central archive would provide interim access.
There would be no requirement to use my source archive for your Slackhammer instances, of course.  Maintaining your own archive would give you faster access and assured continuity, in case my archive fell down.  The more, the merrier.

What is a Slackhammer "binary archive"?
A Slackhammer binary archive is a filesystem directory containing one subdirectory per package, each containing all of the Slackware .txz .txt and .asc built for that package.
These can be Slackware packages built from source locally, or pre-built packages imported from elsewhere (such as an official Slackware release).
Thus a Slackhammer instance does not need to be built entirely (or at all!) from sources, following the long and proven Slackware practice of keeping binary packages from previous releases.  If a package ain't broke, why rebuild it?
This is a separate component for many of the same reasons the source archive is.  Several Slackhammer instances could share the same binary archive, avoiding potentially prohibitive data duplication.  Also, if a user is uninterested in building packages, there is no need to have a source archive at all.  Slackhammer can operate just with a binary archive.

What is a Slackhammer "metarepo"?
A Slackhammer metarepo is a git repo containing the metadata related to each package (.SlackBuild scripts, patches, slack-desc, etc), similar to sbo's git repo.  It would also contain scripts for generating distribution end-products (such as initrd images).
It would also contain the metadata describing:
  • Which .SlackBuild scripts have worked with which source archives on which target platforms,
  • Build order for interdependent packages (qv SFS threads on LQ),
  • References to bug reports,
  • References to CVEs (security vulnerabilities),
  • Tests,
  • Test results,
  • The location of the source and binary archives the metarepo uses.
This is a separate component because it encapsulates resources which could be re-used by several Slackhammer instances.

What is a Slackhammer "instance"?
A Slackhammer instance is a git repo containing the metadata describing a Slackware-like distribution targeting a specific architecture.
The instance specifies:
  • The target architecture,
  • What packages are in the distribution,
  • What versions of package components are in each package,
  • Which .SlackBuild script is used to build each package,
  • What patches and other secondary files are included in each package,
  • What toolchains and global toolchain options are used when building packages,
  • A log of changes,
  • The location of the metarepo the instance uses.

What are some Slackhammer use cases?
If you are a Slackware user, you could use Slackhammer to test a new Slackware release before adopting it, or test a package update before deploying it.
If you are a user with high performance requirements, you could use Slackhammer to recompile Slackware packages with more aggressive and/or processor-specific optimizations.
If you are a Slackbuild package developer, you could use Slackhammer to test your packages for intercompatibility with other Slackware packages.
If you are like me, you might be curious about emerging trends in Slackware's core packages.  Since slackhammer-archiver would archive newer versions of source tarballs as they become available, reports run against these source tarballs would provide a forecast of sorts.
If you are completely batshit crazy, with way too much time on your hands, you could use Slackhammer to create and manage your own Linux distribution forked from Slackware.

What is the status of Slackhammer?
Slackhammer is very much a work in progress, and all of the above is subject to change!  A github link will appear here when there's anything worth sharing.
I'm currently working on filling in holes in the package-tracking data blob used by slackhammer-archiver, and at the rate I'm going it will take months just to get that done :-P
If you have questions, suggestions, rude retorts, etc, come chat with me (ttks) in ##slackware-help channel on freenode.