shedmake is a command-line utility included in all Shedbuilt system images that automates the compilation, installation and distribution of packaged software. It aims to provide a number of useful features to mitigate the tedious, error-prone aspects of source-based software distribution while remaining approachable for newcommers to the hobby. You can peruse the source, report issues and submit pull requests from the repository page on GitHub.
The following applies to version 1.0.1 of the utility.
shedmake is typically invoked with an action, object, and if necessary, some options:
shedmake <action> <object> <option 1> <option 2> ...
An option common to nearly all actions is
-v) which provides more information about what the
shedmakescript is doing behind-the-scenes. It's needed when diagnosing build failures and other issues but can otherwise be left off if you don't want your terminal to be flooded with messages.
Here are few of the most commonly used actions
What's likely to be your most frequently selected action, 'install' takes the package referenced by its object and installs it in the root filesystem or other location of your choice, compiling it if necessary. The object may refer to a package present in a remote or local managed package repository, or else be the path to any folder containing valid packaging information. Root privileges are required when installing a package from any managed repository and whenever the destination is the root filesystem or any other filesystem where normal users lack needed permissions. If the package contains them, the
postinstall.sh scripts will be executed prior to and just after install files are written to the destination, respectively. Successful installations are recorded in the 'install' subfolder of the package.
To perform a typical installation of the 'brogue' package mentioned above, try:
sudo shedmake install brogue
To install the 'linux' package which supplies the Linux kernel verbosely, installing all needed dependencies, try:
sudo shedmake install linux --verbose --install-dependencies
shedmakewill attempt to resolve all install dependencies listed in
package.txtprior to installing the current package. If required packages are not installed, installation will fail. You can pass
-d) to automatically install required packages or
--ignore-dependenciesto skip this step.
shedmakeonly acts on packages in managed repositories. To build, install, or perform other actions on a package directory located elsewhere you must pass the
When an alternative install root is provided to 'install' the
postinstall.shscripts will, if present, be executed in a chroot environment.
As you might expect, 'build' compiles a source package and optionally compresses the resultant binary and other installation files into an archive. This action can be performed not only on packages in managed remote and local repositories, but on any folder containing valid packaging information. Upon successful completion, a file whose name references its metadata (of the form NAME-VERSION-REVISION.tar.xz) will be created in a 'binary' subfolder in the package. To compile the 'brogue' package and store the resultant binary you may do the following:
sudo shedmake build brogue --cache-binary
shedmakewill attempt to resolve all build dependencies listed in
package.txtprior to compiling. If required packages are not installed, the build will fail. You can pass
-i) to automatically install required packages or
--ignore-dependenciesto skip this step. Assuming your user can write to the package folder, it is not necessary to have root privileges when building a package outside of a managed repository. The 'build' action works by invoking the
build.shscript in the package folder with necessary environment variables. Compilation is performed in a temporary directory that is removed automatically.
info action prints out helpful information concerning the specified package, including its installation status:
shedmake info linux
The 'add' action is used to add a single package to a specified local managed package repository given the HTTP/S URL of its git repository. By default, it will add it to the first local respository listed in the configuration file at
shedmake get https://github.com/shedbuilt/brogue.git default
This will add the 'brogue' package to the 'default' local repository present in
/var/shedmake/repos/local in Shedbuilt standard system images.
Because the 'add' action modifies repositories managed by
shedmake, the user invoking it must either be in the
shedmakegroup or have root privileges.
The 'add-repo' action adds a remote package repository to
shedmake's managed packaged repositories in
/var/shedmake/repos/remote given the HTTP/S clone URL of its git repository. Once added, packages from the remote repository can referenced by name in
sudo shedmake add-repo https://github.com/myaccount/myrepo.git
You can use the
--renameoption to specify the name of the folder into which the repository will be cloned in. By default it will be the final component of the URL, sans
The 'uninstall' command removes the files previously copied to disk by the
install action. It will not, however, remove the package from its managed package repository.
sudo shedmake uninstall brogue
This action looks for updates to the packages in the remote or local managed repository named as its object. If the named repository is remote, this will pull in the latest versions of the packages selected by the maintainer of the remote repository. For local repositories, this action look at the origin of each individual package and pull in the latest version targeting the installed Shedbuilt release (i.e. the tip of the branch corresponding to the RELEASE named in
Updating a repository does not automatically install the updated packages. Use the various 'upgrade' commands below to install updated packages.
To update just the 'system' package repository, you can type:
sudo shedmake update-repo system
'update-all' performs the 'update-repo' action on all remote and local managed packaged repositories listed in the configuration file at
/etc/shedmake/shedmake.conf. This command takes no additional options.
sudo shedmake update-all
The 'upgrade' action, which takes as its object the name of a package in any remote or local managed package repository, compares the version information in the package metadata to against that in the 'install' subfolder. If the two differ, the 'install' action is performed, updating the installed version to that specified by the packaging. To upgrade the 'brogue' package, one would type:
sudo shedmake upgrade brogue
If the latest installation recorded in the 'install' folder matches the package's current version metadata, no action is performed.
'upgrade-repo' performs the 'upgrade' action on all packages in the specified remote or local managed package repository. To upgrade all the packages in the 'system' repository, simply type:
sudo shedmake upgrade-repo system
'upgrade-all' performs the 'upgrade-repo' action on all remote and local managed packaged repositories listed in the configuration file at
/etc/shedmake/shedmake.conf. This command takes no additional options. To install all available upgrades, type:
sudo shedmake upgrade-all
status action tells you whether or not a package is installed and, if so, whether or not it's up-to-date.
shedmake status brogue
Elevated privileges are not required for the
statusaction which does not affect package files.
repo-status action provides information about installed and uninstalled packages in the specified repository as well as the availability of upgrades.
shedmake repo-status system
Elevated privileges are not required for the
repo-statusaction which does not affect package files.
The following are commands that you'll probably use less frequently, but are handy when performing packaging tasks.
create you can easily make a new package to build software and distribute it to the Shedbuilt community. Template versions of the required
.gitignore files are automatically copied into a new folder at the provided path:
shedmake create mynewpackage
--originoption allows you to specify an SSH or HTTPS git repository on GitHub or another service that has been established to host the package. You can then use the
pushaction to perform the initial commit and submit subsequent packaging revisions.
create-repo produces a new local managed package repository to host your own packages locally and currate packages to share with the community. The provided name is used to create a new folder for the repository in the local repos directory specified in
/var/shedmake/repos/local by default):
shedmake create-repo myreponame
--originoption allows you to specify an SSH or HTTPS git repository on GitHub or another service that has been established to host the package repository. You can then use the
push-repoaction to perform the initial commit and subsequent packaging revisions.
If you supplied an
--origin when creating a new package with the
create action you can use
push to perform the initial commit and submit subsequent packaging revisions:
shedmake push mynewpackage
If you supplied an
--origin when creating a new local package repository with the
create-repo action you can use
push-repo to perform the initial commit and submit subsequent updates:
shedmake push mynewpackage
This action downloads the source code for the specified package and caches it in the package's
source folder. This is handy if you need to build a package without Internet connectivity at a later date.
sudo shedmake fetch-source brogue
The basic 'clean' action takes the name of a package in a managed repository or a local package folder as its object and deletes the 'binary' and 'source' subfolders used to cache installation and source archives, respectively.
sudo shedmake clean brogue
'clean-repo' simply performs the 'clean' action on all the packages in the managed remote or local package repository specified as the object. The following will delete all cached source and binary archives in the 'system' package repository:
sudo shedmake clean-repo system
There is no harm in executing this command as source files will be fetched again if needed and binary archives created from them on demand.
This action performs 'clean-repo' for every remote and local managed package repository listed in the configuration file at
/etc/shedmake/shedmake.conf. It takes no object and has no supported options.
sudo shedmake clean-repo
To manually delete any files orphaned when upgrading from the previous version of a package to the latest, you can use 'purge':
sudo shedmake purge brogue
This is done automatically when upgrading packages for which it is known to be safe to delete old files. When working with packages that install software libraries exercise great care when using
cleanupas there may yet be software installed that depends on the earlier version.
This just prints out the installed version of the
Typically used for bulk installation during the bootstrapping process,
shedmake offers batch versions of a number action that allow you to perform the same action on a list of packages in a file. Each line in a Shedmake List (
.sml) file lists the package name, followed by options. Additional options specified after the
.sml file that will be applied to all packages in the list.
Shedmake Lists are files typically suffixed with the
.sml extension that contain one or more lines of objects and options to be passed to a single
shedmake action. The action itself is never specified in the Shedmake List. For example, let's consider the following
binutils gmp mpfr mpc gcc --skip-postinstall
If passed to the
install-list action, it install (compiling if needed) the four listed packages with the options passed to
shedmake on the command-line, plus
shedmake install-list compiler.sml --install-root /mnt/mycrazyexperiment
This batch action builds all of the packages listed in the supplied Shedmake List (
shedmake build-list thingsToMake.sml --strip no
This works the same way as the above, installing all of the packages in the supplied list and passing along any normal install options specified in the file and on the command line.
shedmake install-list stuffToInstall.sml --device orangepi-pc
You can add a number of packages to a local package repository at once using the
add-list action. The package repository URLs must be listed in the supplied
shedmake add-list stuffToAdd.sml mylocalrepo
This action downloads source files for all the packages listed in the supplied
.sml file. As with
fetch-source, no options are supported.
shedmake fetch-source-list stuffToFetch.sml
To upgrade a batch of installed packages to their respective package versions, invoke
upgrade-list with a Shedmake List (
.sml) file containing their names.
shedmake upgrade-list stuffToUpgrade.sml
To upgrade all the packages contained within a set of managed remote or local package repositories, use the
shedmake upgrade-repo-list reposToUpgrade.sml
To pull in the latest packaging available for software in a set of managed remote or local package repositories, you can use
shedmake update-repo-list reposToUpdate.sml
You can use
clean-list to remove cached source and binary archives from a list of packages.
shedmake clean-list packagesToClean.sml
Last and almost certainly least, if you want to clean out all the packages in a set of managed remote and/or local package repositories, give
clean-repo-list a try:
shedmake clean-repo-list reposToClean.sml