Shedbuilt automates the compilation, installation, upgrade and removal of software using a tool called shedmake. The goal of shedmake is to provide much of the functionality of sophisticated package managers in popular GNU/Linux distributions while being extremely approachable for those learning how to build open-source software. shedmake is really nothing more than a simple shell script, about a thousand lines in length. It relies on only a handful of common utilities and will happily run on any GNU/Linux system that uses bash as its shell. To get started using shedmake to manage and create your own packages, let's first go over some essential concepts.
shedmake manages software that has been wrapped in bundles called 'packages'. Each package has a unique name used to refer to it when performing a shedmake action such as install. A Shedmake Package contains, minimally, some basic information about the software, such as its name, version and where to download it, as well as recipes for compiling and archiving it. As you'll later see, a package is really nothing more than a folder containing a handful of text files.
Because Shedmake packages are nothing more than folders, no additional rigamarole is needed to create one and use it with shedmake. If you create a package in, say, your home folder ,that package is considered 'unmanaged' and you'll need to pass shedmake its path for it to work on it. shedmake also allows you to install and create 'managed' packages which can be acted on merely by specifying its unique name. Managed packages can also be upgraded when the package maintainer makes an update available.
Packages can be grouped together into collections called repositories. All of the packages included in Shedbuilt Standard System images, for instance, are part of the shedbuilt-system package repository, hosted on GitHub. All 'managed' packages are stored in the package repositories found in /var/shedmake/repos.
Package repositories such as shedbuilt-system that are managed by someone else and that you subscribe to are referred to as 'remote' repositories. Those that you currate yourself are called 'local' repositories. If you choose to publish one of your 'local' repositories, it will be a 'remote' repository for those who subscribe to it. shedmake uses Linus Torvald's git version management tool to synchronize updates between local and remote package repositories.
Remote repositories are located in
/var/shedmake/repos/remoteand local ones in/var/shedmake/repos/local.
Still with me? I hope so. The next section will explain all of the ways shedmake can act on packages, the structure of which we'll dig into thereafter.