slackmatic faq

Why Slackware?

Patrick Volkerding's Slackware is a mature, stable, and flexible Linux platform. It is the longest-lived of current Linux distributions and consistently remains among the most popular. Its enduring popularity comes despite an utter lack of marketing hype and fanfare.

Slackware aims for simplicity, stability and reliability. It provides a base system that is straight-forward to administer, without the over-engineered "sophistication" of some other distributions. With Slackware you know what to expect, no surprises.

While not a "bleeding edge" distribution, Slackware does keep pace with current developments in the Linux kernel and a base set of packages. After installating a base system, it is then easy to track the incremental changes in Slackware-current and keep a system up-to-date.

Whether you need a desktop workstation, a backroom server, an embedded firewall appliance, or a home entertainment system, Slackware makes a good solid base on which to build.


Why slackmatic?

Slackware itself is a package-based distribution, providing the speed and convenience of working with pre-compiled packages.

Sometimes, though, you want or need to develop additional packages from source code. The "Slackware Way" of building packages from source is through SlackBuild scripts. SlackBuilds are stand-alone bash scripts that perform all the steps of unpacking, patching, compiling and constructing a Slackware package from source.

Since each SlackBuild is its own stand-alone shell script, though, developing a collection of SlackBuilds can become a tedious and repetitive process. Moreover, SlackBuilds leave out some of the steps of building a package, such as fetching the source code from a remote server.

And if you ever need or want to change the package policies or compiler options for your package collection, you need to go back and edit each and every SlackBuild script.

slackmatic is an alternative package build system. It centralizes the repetitive parts of building a package, so that the development of BUILD.rc scripts can be simplified. By centralizing the common elements of package building, slackmatic can also help ensure that the resulting packages adhere to Slackware conventions.

Finally, slackmatic offers access to a growing collection of distributed repositories through this website. This makes it possible to leverage the efforts of individual slackmatic developers into a large and increasing variety of available software.


Is slackmatic safe?

Well, slackmatic tries to be safe.

For one thing, slackmat-build is designed by default to require non-root privilege. That is, it will fail whenever you try to run it as root, unless using the -R option to override this feature.

This helps protect your root filesystem from accidental clobberage during builds, as in cases where the BUILD.rc file is improperly written.

Internally, slackmat-build uses fakeroot from the Debian project to enable creation of packages by non-root users. The fakeroot utility "pretends" to be root, and the package tree archived by makepkg will appear to have root permissions only during the slackmat-build process.

Otherwise it is risky to run the slackmat utilities with root privileges, just as it is risky to run Slackware's own package management utilities. Your system is vulnerable to accidential or intentional malice during the following:

  • Execution of commands within the BUILD.rc function during package construction.

  • Execution of commands during the configuration and make of the source code.

  • Execution of commands within the doinst.sh file during package installation.

To mitigate these risks, consider the following:

  • Set up a dedicated build host, to be used solely for the purpose of building and testing packages. Then transfer and install tested packages onto your target systems.

  • Carefully review the BUILD.rc file and any doinst.sh scripts for content, especially for any file operations outside the scope of the $PKG directory.

  • Notify the package maintainer and the slackmatic lists of any problems.


Does slackmatic resolve dependencies?

No, slackmatic (like Slackware) does not provide any explicit support of dependency resolution among packages. Instead, each port README file should document the dependency requirements for each package.

However, slackmatic ports may optionally be designed to support the dependency resolution features of third-party tools such as slapt-get. For example, any slack-* files in the install sub-directory of a port are automatically copied into the package. Then you can setup your own repositories of pre-compiled packages that may resolve dependencies automatically.


Why rc?

The slackmatic system is based on rc, the Unix port of the Plan 9 shell. So all the slackmatic BUILD.rc scripts are written in/for rc.

rc happens to make an excellent command processor. It is simple, lightweight, with a clean syntax that is at once familiar and easy to master.

rc itself has very few built-in functions, depending instead on the classic Unix toolset and connecting commands through pipelines. With a few sed, grep, and cut calls, rc can accomplish much of what can be done with other scripting tools, yet with a fraction of the overhead.

Finally, we have found that rc builds cleanly with the dietlibc library. This provides an extremely small, statically-linked executable. The dietlibc build of rc is also used as the command processor for the run scripts of services supervised by daemontools and runit.


Why dietlibc?

dietlibc is Felix von Leitner's alternative Standard C library for Linux. It is designed to produce very small executables compared to glibc, the GNU Standard C library.

Applications linked against dietlibc are very small, load quickly, and have no shared library dependencies. The use of dietlibc can also help when building systems with memory and/or disk constraints.

Certainly not all applications are suitable or appropriate for dietlibc. It is best used for standalone, non-interactive applications, such as servers and daemons. And of course, the application has to be written in C.

slackmatic was designed make it easier to take advantage of dietlibc. Although it is never necessary to use/install dietlibc if you choose not to, many ports are available that will automatically benefit from it.


Why httpup?

The httpup utility by Johannes Winkelmann is borrowed from the CRUX Linux distribution to allow users to synchronize a collection of slackmatic build scripts with remote repositories.

The use of httpup enables decentralized development and hosting of slackmatic repositories. Although there are other file synchronization protocols, httpup uses the ubiquitous and accessible HTTP protocol for file transfer. This makes it easy for developers to create and publish their own repositories, and both developers and users need not worry about special firewall configurations or uncooperative hosting policies.

It would be nice to have a dietlibc-compatible version of the httpup utility, though, and someday we may actually get around to writing one.