toast - build and install programs from source
toast [ OPTION ... ] [ COMMAND ] [ ARGUMENT ... ]
toast is a simple, self-contained tool for downloading, building, installing, uninstalling and managing software packages. Unlike traditional package-management systems, toast is primarily intended to work directly with software distributed as source code, rather than in some precompiled or specialized binary format, such as RPM. Binary packages are also supported.
toast is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
toast is designed to be used in any of three ways:
Installing and managing software in the home directory of a non-root user on a multi-user system. For example, I like to be able to run valgrind, xdaliclock, Opera, and a few other programs on the Linux cluster at work without having to bother the IT department about installing or supporting those packages.
Installing and managing software packages in parallel to those installed by a conventional package manager. For example, if I were maintaining a computer system running some kind of mainstream Unix-like OS, it might be convenient to be able to quickly install the latest OpenSSH from source into /usr/local in order to work around a security vulnerability, and then conveniently remove it once my vendor or distribution releases an official package for that version.
Installing and managing all software for an entire Unix system; that is, using toast as the one true package manager for the system. This is what I do on my (single-user) Linux box at home.
Use #1 seems to be by far the most common in practice. As far as I know, I'm the only one crazy enough to attempt #3, and no one bothers with #2. In general, it's probably a good idea to use a real distribution (such as Debian), and to use its native package management system whenever possible, rather than using toast to replace it or go behind its back.
toast itself is known to work with Perl 5.005_03 through 5.8.x under Linux, FreeBSD and Cygwin, without relying on the presence or absence of any Perl modules or other tools. Perl is available for download at http://www.cpan.org/src/stable.tar.gz. Although it isn't required, toast get works better if you have GNU wget; use toast arm wget to download and install it if necessary. Additional requirements for toast build vary according to the package being built.
To have the latest version of toast download and install itself, run one of the following commands. The first requires GNU wget; the second relies on the GET utility that comes with the LWP Perl module; the third uses telnet.
wget -O- http://toastball.net/toast/toast|perl -x - arm toast
GET http://toastball.net/toast/toast|perl -x - arm toast
echo GET /toast/toast|telnet toastball.net 80|perl -x - arm toastIf you ran one of the above commands as root, toast should now be installed in /toast with appropriate symlinks under /usr/local, and you should be all set. If you ran one of the command as a non-root user, toast will have installed itself and everything it needs under $HOME/.toast, and you'll probably need to add $HOME/.toast/armed/bin to your PATH environment variable in order to be able to use toast and any other packages it installs. For example, in a Bourne-like shell:
PATH=$HOME/.toast/armed/bin:$PATHIf you would like to use any man pages, info pages, libraries or header files installed by toast, you may also want to adjust MANPATH, INFOPATH, LD_LIBRARY_PATH, or CFLAGS as appropriate. Note that setting LD_LIBRARY_PATH may have unintended consequences; for more information, search the Web for LD_LIBRARY_PATH considered harmful. If your C compiler is gcc, you may be able to use the CPATH environment variable instead of messing with CFLAGS; see the gcc documentation for details.
The above procedure is by no means required in order to install or use toast. Both the uncompressed toast script and an official compressed tarball distribution containing toast are available for download at http://www.toastball.net/toast/. The unmodified toast script can be copied to and run from any location, and you can use toast man to view the man page without having to install it first. The default option settings should be sensible, and any necessary directories will be created on demand.
A GNU-like configure program (OK, symbolic link) is also provided with the official toast distribution for your convenience. You can supply an alternate installation directory prefix with ./configure --prefix=foo, or keep the default prefix of /usr by running ./configure without arguments. Then run make, become root if necessary, and run make install, which will install both the toast program and a man page. Sadly, toast's configure script does not support most of the other command-line options and features of configure scripts produced by the real GNU autoconf.
Adds new packages to the repository by storing URLs. Use this command to store package file locations without actually downloading anything. Each PACKAGE must specify at least one URL or file unless the autofind option is enabled. Absolute and relative pathnames are automatically translated into file URLs. If the given package has already been added, the command merely compares the given URLs against those already stored and gives an error if they don't match; use toast remove or toast change to specify new URLs for an existing package.
Ensures that the given packages have been downloaded. Implies toast add. If no arguments are given, acts on the latest version of every existing package. After this command completes successfully, other commands will be able to operate on the package without downloading any additional files from the network. If a given package is already stored, the existing downloaded files are silently preserved; use toast purge to force them to be downloaded afresh. toast get has rudimentary built-in support for file and http URLs. If GNU wget is installed, toast get will use it to fetch http, https, and ftp URLs. If ssh is available, toast get can use it to fetch (non-standard) URLs of the form ssh:/[username@]hostname/absolute/path/to/file.
Ensures that the given packages are compiled and ready. If no arguments are given, acts on the latest version of every existing package. Packages that already have at least one built or armed build (as reported by toast status) are skipped by this command without causing an error; use toast rebuild to force such packages to be rebuilt. Building may involve implicitly invoking toast get, decompressing and extracting archives, applying patch files, compiling a new build of the package and installing it in a build-specific directory tree. Supported archive formats include compress, gzip, bzip2, zip, rpm, cpio, tar, shar, patch, and most combinations of the above. You don't need to have RPM installed to extract .rpm files; gzip and cpio usually suffice. Archives should contain either precompiled binaries or source code, which will be identified and/or built according to heuristics too mind-numbing to describe completely; in the case of source files, a configure script, Makefile or similar is often required. Many options can influence this command's behavior; see the options reference for full details.
Installs symbolic links to allow builds to be used. This is perhaps the most frequently used toast command. It is normally required before programs compiled by toast build or toast rebuild can be run. If no arguments are given, acts on the latest version of every existing package. If no explicit build number is supplied for a given package, toast build is implied, and the latest built or armed build is armed. If a build to be armed is already in the armed state, this command has no effect. The armdir option controls where the symbolic links to the files in each armed build will be installed; the default location is /usr/local (for root) or $HOME/.toast/armed (for everyone else). Non-root users might want to add $HOME/.toast/armed/bin to the $PATH environment variable to make it easier to run armed packages. Existing links to other builds are moved out of the way if necessary, and the corresponding builds are still considered to be armed.
Forces packages to be built or rebuilt. If no arguments are given, acts on the latest version of every existing package. A new build will be created as if by toast build for every package given, even if the package has already been successfully built. Each package can have any number of independent builds. Builds for a given package are automatically assigned sequential numbers starting from 1. Many options can influence this command's behavior; see the options reference for complete details.
Checks for a later version of an existing package. If no arguments are given, this command acts on the latest version of every existing package. The existing package's URLs are used as a starting point to locate the new version. If the filename component of a given URL doesn't appear to contain the package's version number, that URL will be left unmodified for the new version; otherwise, the directory portion of the URL will be immediately downloaded and searched for a similar URL containing a higher version number. The command fails if no URLs would change or if no single consistent newer version for all version-containing URLs can be found; otherwise, the highest eligible version is used for all modified URLs and the package itself. The command performs an implicit add, get, build or arm on the extrapolated URLs so as to match the state of the given existing version, except that an implicit arm will become an implicit build if the autoarm option is disabled.
Deletes symlinks created by toast arm. This works by removing symbolic links to the given build and replacing any links that had been moved out of the way. No error occurs if no such links exist. If no build number is given, all armed builds are disarmed. If the package version number is also omitted, all armed builds belonging to packages with the given name are disarmed.
Removes intermediate files and broken builds. If no arguments are given, all builds are cleaned. If no explicit version and/or build number is given, all matching versions and/or builds are cleaned. Cleaning a broken build removes the build entirely; otherwise only files that are not required by toast arm are removed from the build. These typically consist of files created directly by toast as part of the build environment, extracted source files, and intermediate files created by the package itself during compilation. Some kinds of binary packages that do not involve intermediate files never require cleaning, and toast build and toast build may automatically perform this step if the autoclean option is enabled. Builds that are still in the building state (as reported by toast status) are silently ignored by this command.
Deletes one or more builds. If no version and/or build number is given, all matching builds are disarmed. If one of the builds to be demolished is currently armed and the autodisarm option is disabled, toast demolish reports an error and no builds are deleted; otherwise, toast disarm is implied. Demolishing a package reverses the effects of toast build or toast rebuild (and, optionally, toast arm), but never those of toast get or toast add.
Deletes files downloaded by toast get. Deletes toast's local copy of the original archive used to build the given package or set of packages. Existing builds are not affected by this command, but creating a new build will implicitly reinvoke toast get. If the autopurge option is enabled, toast build or toast rebuild may implicitly invoke this command.
Deletes a build, a package, or a set of packages. Removing a build has the same effect as toast demolish. Removing a package deletes all of its builds and additionally reverses the effects of toast get and toast add. If any of the builds to be deleted is currently armed, and the autodisarm option is disabled, toast remove reports an error and nothing is removed; otherwise toast disarm is implied.
Renames an existing package or set of packages. The package or packages must already exist. NEWNAME uses the same syntax used to refer to an existing package or build, except that the destination package must not already exist and must contain the same number of slash characters as PACKAGE. This command can also be used to renumber builds. Currently, armed packages or builds must be disarmed before they can be renamed.
Changes the stored URLs for an existing package or packages. Use with caution! Each package must already exist, and at least one URL must be given explicitly for each. The URL or URLs previously stored for each package by toast add will be discarded and replaced by the given URL or URLs. No further action is taken; in particular, neither toast get nor toast purge is implied. Note that it is often simpler and safer to remove and then re-create a package than it would be to use this command.
Displays information about packages and builds. If invoked without arguments, displays information about all packages and builds. A package is marked as stored only if the original files have been downloaded by toast get and haven't been deleted by toast purge. The package URLs may also be listed; see the showurls option. Every package has zero or more builds, each of which is either building (if toast build or toast rebuild is still running), broken (if it failed), built (if it succeeded), or armed (by toast arm). In the last two cases, the build will be marked (not clean) if intermediate files created by toast build have not yet been removed by toast clean.
Summarizes usage information from the toast man page. If invoked without arguments, displays a one-line summary of every command. If invoked with an argument, displays a longer summary of the given topic, which may be a command name, an option name, commands or options. If toast itself is invoked without any arguments, toast help is assumed. Note that most information displayed by this command is taken directly from a subset of the toast man page.
Displays the complete toast man page. You're either reading the man page now, or reading something that was derived from it (such as the output of toast help). This command is supposed to behave about the same way man toast would, but it doesn't require the man program or the toast man page to be installed. If standard output is a tty, the man page is formatted using Pod::Text::Overstrike, Pod::Termcap, Pod::Text or the rudimentary internal formatting routine used by toast help, and the formatted page is piped to $MANPAGER, $PAGER, less -ir, or more, or dumped directly to the terminal as a last resort. If output is redirected to a file or pipe, the man page is rendered as plain text using Pod::Text if available or the internal routine otherwise. If you want more control over the output, try feeding the toast script itself to pod2text, pod2html, pod2man, or pod2latex, all of which are command-line utilities that accepts lots of exciting switches and things and that come bundled with recent versions of Perl.
Most commands take one or more arguments denoting packages or builds. Such arguments usually follow one or more of the forms below. Note that not all commands accept all of these forms; in fact, some commands (like toast help) accept none of them.
This syntax can be used to refer to an existing package. If the package does not exist and the autofind option is set, it will be located automatically; if VERSION is omitted, the latest available version will be used. If NAME matches a previously-added package and VERSION is omitted, the latest existing version is used, except when the documentation for the command specifically says that it affects all versions or operates on sets of packages, in which case all versions are affected. Examples: wget, gcc/3.2.2, openssl/0.9.7b
This syntax is used to refer to an existing build of an existing package. Builds are numbered consecutively starting from 1. Many commands don't accept individual builds as arguments; the usage information for those commands that do accept builds always uses the term BUILD explicitlly. Examples: xdaliclock/2.19/1, glibc/2.3.2/4.
This syntax is most often used to implicitly add a new package by URL, though many commands also allow it to be used to refer to an existing package. If the package name and version are omitted, they will be guessed based on the filename portion of the URL; if the package already exists, it will be found only if the guessed name and version match those used to add it. An error will occur if the given package exists but has different URLs. Examples: ftp://alpha.gnu.org/gnu/tar/tar-1.13.25.tar.gz, ps/3.1.8: http://procps.sf.net/procps-3.1.8.tar.gz.
This syntax can be used to add a new package from a local file. The given path is automatically translated into an absolute file URL. Unlike a file URL, the path will be checked as soon as it is parsed to ensure that it refers to a readable file; if it does not, a fatal parse error will occur and the entire command will not be invoked, even if previous arguments were parsed without error, the package already exists, or the stoponerror option is disabled. Examples: myprog/0.1test: myprog.zip, /home/anandam/gdb-5.3.tar.gz, ../../mnt/ain/ain/opt/stow/xplanet/xplanet-1.0.1.tar.gz.
This syntax can be used to add a package that requires multiple URLs and/or local files by grouping them between literal square brackets. As with the previous two forms, the name and version number may be omitted, in which case they will be guessed from the given filenames. If the filenames are very dissimilar, only the first will be used to guess the package name and version number. Otherwise, the order of URLs and/or paths is not significant. Examples: [ http://www.kernel.org/pub/linux/kernel/v2.4/linux-2.4.20.tar.bz2 linux-2.4.20-config.tgz ssh://vulture/home/matt/linux-2.4.20.patch ], [ http://ftp.gnu.org/gnu/glibc/glibc-{,linuxthreads-}2.3.2.tar.bz2 ], XFree86/4.3.0: [ X430src-[1-7].tgz ]. (The last two examples respectively involve brace and glob expansion performed by your shell).
Every command that accepts a PACKAGE argument will accept several PACKAGE arguments in sequence, so multiple files or URLs will always be treated as distinct packages unless they are explicitly grouped into a single package using square brackets as shown above. For instance, toast add * puts each file in the current directory in its own package, while toast add [ * ] tries to combine them all into a single package.
Defines the root of the directory tree toast uses to store and build all packages. STOREDIR must be given as an absolute path or a fatal error will result. toast add and commands that explicitly invoke it will create STOREDIR if it doesn't already exist. Default: /toast if invoked by root, $HOME/.toast otherwise.
Defines the directory under which toast arm creates symlinks to compiled package files in STOREDIR. toast build also tries to use this value as a prefix when compiling most packages. With few exceptions, ARMDIR should point to the same directory when arming a given package that was used when building that package. If ARMDIR is not given as an absolute path, it is taken to be relative to STOREDIR. ARMDIR and should probably not contain STOREDIR, and should probably not be contained by STOREDIR either unless ARMDIR is armed, though these restrictions are not enforced. It's usually a good idea for ARMDIR to be /usr or /usr/local if feasible, since some broken packages may not work if installed in a different location. Default: /usr/local if invoked by root, armed otherwise.
When invoked as root, toast build will unpack, compile, and install packages under USER's UID and GID as returned by getpwnam(3). Note that any additional groups (such as those in /etc/groups) will be ignored, as will USER's password, home directory, shell, and so on. Default: toast.
If PROG is non-empty, toast arm and toast disarm will execute it immediately after arming or disarming one or more packages. PROG can contain multiple words and/or shell metacharacters and will be parsed and executed according to Perl's usual conventions, so it can actually refer to more than one program. If PROG returns non-zero (failure), the command will also fail. Default: /sbin/ldconfig if invoked by root, empty string otherwise.
Sets an implicit command to be assumed if toast is invoked with at least one command-line option or argument but no explicit command. COMMAND may be the name of any valid toast command. As a special case, the value help causes toast to print an error message and a list of valid commands if no explicit command is given. Note that invoking toast without command-line options or arguments is always equivalent to running toast help, regardless of this option's setting. Default: help.
Enables or disables verbose command output. When disabled, most commands will produce output only on failure. Some commands, such as toast status, are not affected by this flag. Default: enabled.
When autofind is enabled, toast add and other commands will automatically look up package URLs on freshmeat.net when none have been added previously or given explicitly. If no version number is given either, the latest version listed on freshmeat.net will be used. Default: enabled.
When autochange is enabled, toast get may replace the URLs stored by toast add with the actual URLs of the files it downloaded. This matters if an URL given on the command line points to an HTML page or FTP directory rather than to an actual archive to be extracted and built. In order to ensure consistent results, it is often desirable to store the more specific URLs, especially if autopurge is enabled. If this option is disabled, toast get will still follow links in the usual way, but stored URLs will be left untouched, and future invocations of toast get may end up downloading different files for the same package if new files or links have since been added to a page or directory. Default: enabled.
When autorename is enabled, toast get may try to use information gained after downloading files to attempt to guess a new name for any implicitly added package for which no name and/or version number was specified on the command line or could be guessed from the URLs given. If autochange is also enabled, new URLs are first used to try to guess a new name; if this fails, the contents of the downloaded files are examined. If either method results in a new name being guessed, the package is renamed automatically as if by toast rename, and any further processing continues under the new name. If autorename is disabled, packages with unguessed or partially guessed names always keep the unique names automatically assigned by toast add based on URLs alone (version number will be unknown optionally followed by a serial number for uniqueness; name may have been guessed or may also be unknown). Default: enabled.
When autoclean is enabled, commands that create a new build for a package (such as toast rebuild) implicitly remove any pre-existing broken builds from that package before creating the new build; also, whenever a new build succeeds, it is implicitly cleaned as if by toast clean. Note that newly created broken builds will not be immediately cleaned or removed, even if this option is enabled, so as to make it easier to diagnose build problems. Default: enabled.
When autopurge is enabled, an implicit toast purge will be performed on a package as soon as it is successfully built. Default: disabled.
When autoarm is enabled, toast upgrade and toast rebuild perform an implicit toast arm on every newly created non-broken build whose package already contains another armed build. Default: enabled.
When autodisarm is enabled, toast arm, toast demolish and toast remove each perform an implicit toast disarm on their armed arguments or, in the case of toast arm, on all builds belonging to the same package as its arguments, or to any package with the same name as its arguments if crossversion is enabled. Default: enabled.
When autodemolish is enabled, toast rebuild performs an implicit toast demolish on every other build belonging to the same package as a newly-created, non-broken build. If crossversion is also enabled, other packages with the same name will also be demolished. Default: enabled.
When both autoremove and crossversion are enabled, toast build performs an implicit toast remove on every other package with the same name as the package containing a newly-created, non-broken build. If crossversion is disabled, this option has no effect. Default: disabled.
When crossversion is enabled, the autodisarm, autodemolish and autoremove options will extend their effects to other packages with the same name when appropriate. See the descriptions of those options for details. Default: disabled.
When strictpreload is enabled, toast build will fail unless it can successfully compile a shared library for use with LD_PRELOAD during the make install phase. If strictpreload is disabled, toast build still tries to build and use the shared library, but will do the best it can otherwise. This may allow toast build to succeed in the absence of a suitable C compiler, but it may allow some packages to build incorrectly in some situations. Default: enabled.
When useflock is enabled, some commands (such as toast arm) may try to use Perl's built-in flock() to prevent multiple concurrent invocations of toast from modifying the repository in ways that might corrupt it. Disabling this option is probably not a good idea, but may be necessary in some environments. Note that Perl's flock() will not necessarily use C's flock() routine; see the Perl manual for details. Note also that toast's locking strategy probably isn't foolproof, especially under NFS. Default: disabled under Cygwin, enabled elsewhere.
When reconfigure is enabled, toast build may attempt to pass extra arguments to a package's configure script (such as --enable-shared) and/or Makefile (such as install.man) in order to build or install extra files that the package itself might not build or install by default. This produces improved results for many specific packages (such as QT and XFree86), and may make subsequent packages more likely to build, but it can sometimes break things (usually in a straightforward way), or it may be undesirable for other reasons. If reconfigure is disabled, toast build does not try to do anything beyond the minimum steps required to correctly build and install whatever files the package builds and installs by default. Default: enabled.
When stoponerror is enabled, toast aborts and returns failure as soon as any error occurs. If stoponerror is disabled, only the processing of the current command argument is aborted; any subsequent arguments will still be processed, but toast still issues an error message and returns failure after processing the last argument, even if the last argument was processed successfully. Note that certain types of errors, such as errors parsing the command line, will always cause toast to abort completely, before processing the first argument, regardless of this setting. Default: enabled.
If ignorecase is enabled, package names and version numbers given on the command line are always case-sensitive. If ignorecase is disabled, package names and version numbers that refer to existing packages are treated as if they were case-insensitive only when failing to do so would cause an error. Note that case is always preserved in URLs and when explicitly naming new packages. Note also that it is always legal for two distinct packages to have names and/or version numbers that differ only in case, and that such packages are never treated as if they were related, even if crossversion is enabled.
When showurls is enabled, toast show always displays the stored URLs associated with each displayed package. If showurls is disabled, toast show only displays a package's URLs if a different list of URLs for that package was given explicitly on the command line.
If debugrewrite is enabled, toast build will always generate broken builds. The builds will contain extra debugging information that can be used to help diagnose problems involving packages that build correctly outside of toast, but refuse to build or build incorrect files due to bugs in toast's path-rewriting mechanism. This option currently requires that the strace program be available (or ktrace for *BSD).
Each option's value is taken from the first of the following sources that assigns it a value:
The command line. All options support standard --NAME=VALUE and --NAME VALUE syntax. For boolean options, VALUE can be true, yes, on, enabled, or 1 to enable the option or false, no, off, disabled, or 0 to disable it. Alternately, --NAME can be used to enable a boolean option or --noNAME to disable it. In all cases, the leading double dash (--) may be replaced by a single dash (-), and NAME is case-insensitive (as is the no prefix used to disable boolean options). VALUE is case-sensitive, except for boolean options.
The environment. If option NAME is not given a value on the command line, will be read from the environment variable TOAST_NAME (all uppercase) if it exists. Note that environment variables whose names contain lowercase letters will be silently ignored! In the case of a boolean option, one of the explicit values listed in item 1 must be given.
The configuration file. If option NAME has not been assigned a value through any of the above methods, its value will be taken from a line of the form NAME=VALUE, if such a line exists, in $HOME/.toast/conf, if that file exists. ($HOME specifically represents the value of the HOME environment variable.) NAME is case-insensitive in this context. Any whitespace before or after NAME or VALUE will be ignored, as will any blank line, any line containing only whitespace, and any line with # as its first non-whitespace character. If the file exists but cannot be read or has invalid syntax, an invalid NAME, or an illegal VALUE for a boolean option (an explicit value must be given; see item 1 for allowed forms), toast will normally give an error message at startup and refuse to execute any commands.
The built-in default value. See the full list of options elsewhere in this document for the specific default value used for each option.
Any COMMAND can also be written as if it were a command-line option by preceding it with one or two dashes. For example, toast --help and toast help mean the same thing. Commands do not behave like options in the environment or the configuration file, but see the defaultcmd option above for an alternative.
Environment variables whose names start with TOAST_ may be interpreted as option settings as described above. In addition, various standard environment variables such as PATH, LD_LIBRARY_PATH, CFLAGS and others may directly or indirectly influence toast's behavior, especially when building new packages.
By default, when invoked by a non-root user, toast writes only to the $HOME/.toast directory, which will be created automatically if needed.
toast may be downloaded from http://toastball.net/toast/ under the terms of the GNU GPL.
Please report any bugs, unexpected behavior, unsurprising but inconvenient failures, feature requests, comments, and so on to toast-bugs at the hostname of the toast distribution site, toastball.net.
Known bugs:
- autofind mishandles http redirects (e.g. http://toastball.net/toast)
- gtk+ doesn't seem to build properly when it is already armed
- opera and sleepycat db refuse to build when already armed
- toast arm/disarm can leave info.dir in the wrong state
- gimp will load plugins from other armed versions despite .off suffix
- "toast upgrade gcc" doesn't work (ftp site has a subdir per version)
- autofind fails for: sleepycat db, gcc, latex, gv, GNU arch (?), ogle
- build fails for: jikes, sirc, netcat, lcab, gv
- "toast --autoremove --crossversion upgrade toast" breaks everything
- if x/1/1 is armed and x/1/2 is built, "toast arm x" does nothing
- various unquoted arguments to 2-arg open()
- "toast help verbose" works but "toast help noverbose" doesn'tWish list:
- work around lack of getenv(), mkdir(), etc. in microperl...?
- "toast upgrade" w/o args should imply --nostoponerror or something
- "toast arm" should move armed packages to top of stacking order
- "toast status" should give information about stacking order
- "toast rename" should rename armed packages by rewriting symlinks
- directories in armdir should be read-only (mode 0555) by default
- "toast build" should be able to deal with perl modules
- add "toast check": verify storedir and armdir integrity (and fix?)
- toast get could be more robust w/r/t failures and concurrency
- configure packages to use alternate /etc, /var, etc. when possible
- share rewriting code between command wrappers and shared library
- come up with a better way to deal with gnome (guess dependencies?)
- figure out where to go with "toast edit" (or document it as-is)
- fold archives by URL and/or hash?
- zsh completions!Questions left unanswered by this documentation:
- What are some realistic examples of toast commands?
- How are storedir and armdir structured?
- How does this tool differ from similar tools?
- How can I address common problems not directly caused by toast? /package http://cr.yp.to/slashpackage/management.html
Alien http://kitenet.net/programs/alien/
autopackage http://autopackage.org/
CheckInstall http://asic-linux.com.mx/~izto/checkinstall
Debian http://www.debian.org/
Encap http://www.encap.org/
fakeroot http://packages.debian.org/stable/utils/fakeroot.html
FreeBSD Ports http://www.freebsd.org/ports/
GAR http://www.lnx-bbc.org/garchitecture.html
GARStow http://offog.org/code/garstow.html
Gentoo http://www.gentoo.org/
GNU stow http://www.gnu.org/software/stow/
Graft http://www.gormand.com.au/peters/tools/graft/graft.html
LFS http://www.linuxfromscratch.org/
Linuxports http://linuxports.sourceforge.net/
RPM http://www.rpm.org/
Source Mage http://www.sourcemage.org/
spasm http://www.linux.org/apps/AppId_6909.htmlJacques Frechet
This manual is part of toast. Copyright (C) 2003 Jacques Frechet.
toast is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
toast is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with toast; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA