BS(1) General Commands Manual BS(1)
NAME
bs - build software
SYNOPSIS
bs [ -V | --version ] [ -v | --verbose | -d level | --debug=level ] [
-h | --help ] [ -p | --paths ] [ -n | --simulate ] [ -f file | --con-
fig=file ] [ -k | --keep ] step module
DESCRIPTION
Bs is a tool to execute the steps of the program and package develop-
ment cycles.
It takes two arguments: step specifies the step of a cycle to execute (
prologue, schedule, test, release, make [tarball/package] or epilogue)
and the cycle or cycle-phase name ( source, tarball, pkctrl or pack-
age); module specifies the name of the program or package (which are
assumed to be the same). The steps and their meanings are listed be-
low.
Prior familiarity with the program and package development cycles is
essential.
STEPS
The steps of the program development cycle are these, listed in the or-
der in which they are to be called:
prologue-sources, ps
Run the user-written script specified by the SITE_PRO-
LOGUE_SOURCES_CMD configuration variable. This script should
perform all the actions necessary to bring module to a state
where the program developer can enter the normal program devel-
opment cycle (starting with the schedule-sources step). It is
expected that this script should: create the module directory,
populate it with a minimal set of source files, import it to a
repository (e.g. Git or Subversion)
schedule-sources, ss
Schedule a new release.
test-sources, ts
Test the sources. This means: run some standard tests (e.g.
check the program sources are up to date with respect to their
repository), run module's regression test suite and attempt to
make the tarball.
release-sources, rs
Release the sources. This means: repeat the test-sources step
but tolerate no errors or warnings, finalise the ChangeLog and,
in the repository, copy module/trunk to module/tags/release-id.
make-tarball, mt
Make the tarball.
epilogue-sources, es
Run the user-written script specified by the SITE_EPI-
LOGUE_SOURCES_CMD configuration variable. Typically, this step
is not needed.
After running the above steps, the program developer should normally
wait for an external event (e.g. a bug report or the release of a new
version of a prerequisite library) and then repeat the cycle from the
schedule-sources step.
The steps of the package development cycle are these, listed in the or-
der in which they are to be called:
prologue-pkgctrl, pp
Run the user-written script specified by the SITE_PROLOGUE_PKGC-
TRL_CMD configuration variable. This script should perform all
the actions necessary to bring module.vendor module to a state
where the package developer can enter the normal program devel-
opment cycle (starting with the schedule-pkgctrl step). It is
expected that this script should: create the module.vendor di-
rectory, populate it with a minimal set of package control
files, archive it in a repository and immediately retrieve a
copy of the package control files from the repository.
schedule-pkgctrl, sp
Schedule a new release.
test-pkgctrl, tp
Test the package control files. This means: run some standard
tests (e.g. check the package control files are up to date with
respect to their repository) and make the package.
release-pkgctrl, rp
Release the package control files. This means: repeat the
test-pkgctrl step but tolerate no errors or warnings, finalise
the changelog and and tag the sources with the release ID in the
repository. module.debian/trunk to module.debian/tags/re-
lease-id.
make-package, mp
Make the package.
epilogue-pkgctrl, ep
Run the user-written script specified by the SITE_EPILOGUE_PKGC-
TRL_CMD configuration variable. It is expected that this script
insert the package into a package repository (perhaps using
paa(1)).
After running the above steps, the package developer should normally
wait for an external event (e.g. a bug report or the release of a new
version of the program sources) and then repeat the cycle from the
schedule-pkgctrl step.
In addition, there are the following steps available:
status Report the last successfully completed program source and pack-
age development steps.
CONFIGURATION
Many variables need to be set in the configuration file. See the com-
ments in /usr/share/doc/bs/examples/bs.conf for details.
OPTIONS
-d level, --debug=level Determines how verbose this program will be.
The message types displayed for the different
values of level are as follows: 0 displays no
messages; 1 displays only errors, 2 displays
errors and warnings; 3 displays errors, warn-
ings and informational messages; higher values
display errors, warnings, informational mes-
sages and various messages intended for debug-
ging. The default is 2.
-h, --help Displays a brief usage message.
-p, --paths Lists the compiled-in paths of various files
and directories that this program uses.
-n, --simulate Some external commands that this program runs
may be displayed rather than actually exe-
cuted. BEWARE: different programs implement
different levels of simulation; so do not rely
on -n having no effect!
-v, --verbose Equivalent to -d 3.
-V, --version Prints the program's version number and exits.
-f file, --config=file Set the configuration file. If this option is
not used then the file specified by the
BS_CONFIG environment variable is used and, if
that is not set, a hard-coded default is used
(see ENVIRONMENT and FILES below).
-k, --keep Do not delete the sandbox after use; this
might be useful in diagnosing problems with
the build.
EXIT STATUS
On success bs returns zero. On failure it returns non-zero and dis-
plays a diagnostic message.
FILES
/etc/bs.conf
Default configuration file
ENVIRONMENT VARIABLES
BS_CONFIG Specifies the location of the configuration
file.
EXAMPLES
None.
CAVEATS
Bs builds Debian packages (see deb(5)). It then uses alien(1) to con-
vert that to an RPM (see rpm(8)). It currently lacks support for doing
this the other way round or for other package formats.
Bs supports git(1) and svn(1). Its code to access these has been ab-
stracted into a separate source code file, so adding support for other
repository types should not be difficult.
The configuration file has too many settings.
STANDARDS
This manual page documents version 3.1.4.12 of bs.
SEE ALSO
bs-config(1), alien(1), deb(5), rpm(1), git(1), svn(1), dch(1), paa(1)
AUTHOR
Alexis Huxley <alexishuxley@gmail.com>
COPYRIGHT & DISTRIBUTION POLICY
Copyright (C) 2011-2025 Alexis Huxley
This program 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.
This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of MER-
CHANTABILITY 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 this program; if not, write to the Free Software Foundation, Inc.,
675 Mass Ave, Cambridge, MA 02139, USA.
8 Aug 2025 BS(1)
