mirrors/sbopkg
2
0
Fork 0
mirror of https://github.com/sbopkg/sbopkg synced 2024-09-19 22:40:19 +03:00
Code Issues Packages Projects Releases Wiki Activity

revise documentation

Browse Source 
Major reformatting and some textual modifications of
src/usr/doc/sbopkg-*/* including breaking out the credits from the
script into a detailed THANKS file, renaming and reformatting
ChangeLog.txt into NEWS, renaming the sample queuefiles from *.sqf to
*.sqf.sample, and making lesser modifications to all the other docs.
This commit is contained in:
slakmagik 2011-02-05 03:18:48 +00:00
parent fa831cdd97
commit 482aed1f9b
26 changed files with 1741 additions and 1328 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

445
src/usr/doc/HACKING
View File

@ -1,302 +1,337 @@
# $Id$ SBOPKG HACKING
# vim:set ft=:
We welcome contributions to sbopkg. If you have a bug report or a feature INTRODUCTION
request, please go to the project's Google Code site and use the 'Issue
Tracker' so your bug report/feature request does not get lost:
http://code.google.com/p/sbopkg/issues/list. If you cannot post to the Issue
Tracker, please consider joining the sbopkg mailing list and post your bug
report or feature request there:
http://sbopkg.org/mailman/listinfo/sbopkg-users
As far as hacking on the code, the best thing to do is to checkout the We welcome contributions to sbopkg. If you have a bug report or a
latest version from subversion (see http://www.sbopkg.org/devel.php) and then feature request, please go to the project's Google Code site and use
contribute patches with something like 'diff -Naurp' or 'svn diff -x -p'. the Issue Tracker so your bug report/feature request does not get
Please try to make each patch do one thing and do it well. Also, please do lost.
not combine whitespace or other non-functional changes with functional changes
in the same patch (unless the same lines contain both types of changes).
Basically, just use common sense -- a one line functional change and a typo
correction can be a single patch, rather than two one-line patches.
Please make sure your patches conform to these stylistic points: http://code.google.com/p/sbopkg/issues/list
* Code in Bash. If you cannot post to the Issue Tracker, please consider joining the
sbopkg mailing list and post your bug report or feature request
there.
* Wrap lines at 78 columns. http://sbopkg.org/mailman/listinfo/sbopkg-users
* Expand tabs to spaces. If you cannot join the mailing list, there is an #sbopkg channel on
the freenode IRC network.
* Indent with four spaces at all levels. As far as hacking on the code, the best thing to do is to checkout
the latest version from subversion using something like the
following command:
* Use '[[' wherever possible, vs. '['. svn checkout http://sbopkg.googlecode.com/svn/trunk \
sbopkg-contrib
* Negate tests like '[[ ! foo ]]' instead of '! [[ foo ]]'. (See http://www.sbopkg.org/devel.php for more information.) Then
contribute patches with something like 'diff -Naurp' or 'svn diff -x
-p'.
* write functions in the form: Please try to make each patch do one thing and do it well. Also,
please do not combine whitespace or other non-functional changes
with functional changes in the same patch (unless the same lines
contain both types of changes). Basically, just use common sense --
a one line functional change and a typo correction can be a single
patch, rather than two one-line patches.
my_func() { PATCH/SCRIPT GUIDELINES
# comments here
stuff * Write code compatible with bash 3.1.17 to the latest stable
} version.
* In general, variables do not need to be quoted except in cases where the * Wrap lines at 78 columns.
variable may contain spaces. If unsure, quote the variable just to be safe.
* Use variable names in the form: MYVARNAME except when MYVARNAME is * Expand tabs to spaces.
ambiguous or made of more than two or three components. In that case, use
MY_VAR_NAME.
* If you are going to need a bit of data repeatedly, try to grab it once and * Indent with four spaces at all levels.
assign it to a variable rather than re-obtaining it.
* If you are going to use a combination of several concatenated variables * Use '[[' wherever possible, vs. '['.
multiple times, consider creating a new variable like:
'NEWVAR=$OLDVAR1-$OLDVAR2-$OLDVAR3'.
* Prefer the style: * Negate tests like '[[ ! foo ]]' instead of '! [[ foo ]]'.
if [[ foo ]]; then * write functions in the form:
bar
fi
instead of: my_func() {
# comments here
if [[ foo ]] stuff
then }
bar
fi
(same goes with 'for' and 'while' loops). * In general, variables do not need to be quoted except in cases
where the variable may contain spaces. If unsure, quote the
variable just to be safe.
* The spacing in numeric 'for' loops is: * Use variable names in the form: MYVARNAME except when MYVARNAME is
ambiguous or made of more than two or three components. In that
case, use MY_VAR_NAME.
for ((i=0; i<=10; i++)); do * If you are going to need a bit of data repeatedly, try to grab it
once and assign it to a variable rather than re-obtaining it.
* Prefer shell redirection to piping 'echo' or 'cat'. * If you are going to use a combination of several concatenated
variables multiple times, consider creating a new variable like:
'NEWVAR=$OLDVAR1-$OLDVAR2-$OLDVAR3'.
* Prefer bash variable substitutions to 'tr', 'sed', 'cut', ..., when * Prefer the style:
possible.
* Error messages should go to standard error: if [[ foo ]]; then
bar
fi
echo "Things have gone nuts" >&2 instead of:
* Make return codes meaningful (i.e. if you redirect to stderr try if [[ foo ]]
to return or exit 1 at the same time). then
bar
fi
* When both 'foo' is simple and 'bar' is a one-liner, the conditional form: (same goes with 'for' and 'while' loops).
[[ foo ]] && bar * The spacing in numeric 'for' loops is:
can be used instead of: for ((i=0; i<=10; i++)); do
if [[ foo ]]; then * Prefer shell redirection to piping 'echo' or 'cat'.
bar
fi
However, do not use the following form: * Prefer bash variable substitutions to 'tr', 'sed', 'cut', ...,
when possible.
if [[ foo ]]; then bar; fi * Error messages should go to standard error:
* Use: echo "Things have gone nuts" >&2
[[ foo ]] || bar * Make return codes meaningful (i.e. if you redirect to stderr try
to return or exit 1 at the same time).
only when 'bar' is simple and supposed to be executed on error conditions * When both 'foo' is simple and 'bar' is a one-liner, the
(i.e. almost never) conditional form:
* Multiple conditionals can be done either as: [[ foo ]] && bar
if [[ $CHOICE == 1 ]] || [[ $CHOICE == 0 && -z $CUSTOMOPTS ]]; then can be used instead of:
or if [[ foo ]]; then
bar
fi
if [[ $CHOICE == 1 || ( $CHOICE == 0 && -z $CUSTOMOPTS ) ]]; then However, do not use the following form:
but not: if [[ foo ]]; then bar; fi
if [ $CHOICE = 1 ] || [ $CHOICE = 0 -a "$CUSTOMOPTS" = "" ]; then * Use:
The reasons the third example is not as good as the first two are that it [[ foo ]] || bar
uses single brackets instead of double brackets and uses '-a' instead of
'&&'.
* 'case' statements should be indented as: only when 'bar' is simple and supposed to be executed on error
conditions (i.e. almost never)
case $FOO in * Multiple conditionals can be done either as:
bar ) # Comment goes here
commands
;;
baz* ) # Comment goes here
commands
;;
esac
unless the statements can be short one-liners, in which case the form if [[ $FOO == 1 ]] || [[ $FOO == 0 && -z $BAR ]]; then
case $FOO in or
bar ) short_simple_command ;;
baz* ) simple_short_command; exit ;;
esac
is preferred. if [[ $FOO == 1 || ( $FOO == 0 && -z $BAR ) ]]; then
* Avoid chaining commands with ';' (with the above exceptions). but not:
* Declare local variables as such at the function start. if [ $FOO = 1 ] || [ $FOO = 0 -a "$BAR" = "" ]; then
* Positional parameters to functions should be assigned to local variables, The reasons the third example is not as good as the first two are
one per 'local' statement, before declaring the other local variables (which that it uses single brackets instead of double brackets and uses
can share a single 'local' statement): '-a' instead of '&&'.
local FILE="$1" * 'case' statements should be indented as:
local DIR="$2"
local FOO BAR BAZ
* In general, when wrapping long lines, the part going on the next line should case $FOO in
be indented with 8 spaces if there is ambiguity so as to distinguish the bar ) # Comment goes here
wrap from other lines before and after it. The same would be true for line commands
wraps in conditions. For example: ;;
baz* ) # Comment goes here
commands
;;
esac
if ASD || unless the statements can be short one-liners, in which case the
FGH; then form
echo "Success"
fi
as opposed to: case $FOO in
bar ) short_simple_command ;;
baz* ) simple_short_command; exit ;;
esac
if ASD || is preferred.
FGH; then
echo "Success"
fi
In the latter case, having 'FGH; then' at the same indent level as the echo * Avoid chaining commands with ';' (with the above exceptions).
is ambiguous. On the other hand:
APP=$(grep foo \ * Declare local variables as such at the function start.
really/long/path/to/file)
if foo; then
echo "Success"
fi
is ok since there really is no ambiguity. * Positional parameters to functions should be assigned to local
variables, one per 'local' statement, before declaring the other
local variables (which can share a single 'local' statement):
* Prefer 'foo | bar' over 'foo |bar' or 'foo|bar'. However, if the line local FILE="$1"
barely goes over 78 columns, then removing spaces is OK to keep it on a local DIR="$2"
single line. In other words: local FOO BAR BAZ
foo |bar |baz * In general, when wrapping long lines, the part going on the next
line should be indented 8 spaces beyond the initial line if there
is ambiguity so as to distinguish the wrap from other lines before
and after it. The same would be true for line wraps in conditions.
For example:
is better than if ASD ||
FGH; then
echo "Success"
fi
foo | bar | as opposed to:
baz
* When wrapping between two piped commands, the pipe should be the last if ASD ||
character of the former line. For example, prefer: FGH; then
echo "Success"
fi
some stuff here foo | In the latter case, having 'FGH; then' at the same indent level as
bar the echo is ambiguous. On the other hand:
instead of: APP=$(grep foo \
really/long/path/to/file)
if foo; then
echo "Success"
fi
some stuff here foo \ is ok since there really is no ambiguity.
| bar
when possible. * Prefer 'foo | bar' over 'foo |bar' or 'foo|bar'. However, if the
line barely goes over 78 columns, then removing spaces is OK to
keep it on a single line. In other words:
* Always use $( ... ) instead of ` ... `. foo |bar |baz
* 'Break' and 'continue' should never be used to influence a loop outside of is better than
the function they belong to.
* Avoid indirect recursion (A calls B that calls A). foo | bar |
baz
* [[ -z "$VAR" ]] vs. [[ ! "$VAR" ]] and [[ "$VAR" ]] vs. [[ -n "$VAR" ]]: * When wrapping between two piped commands, the pipe should be the
-n/-z should be used when $VAR contains a computational result and the other last character of the former line. For example, prefer:
form should be used where $VAR is a functional flag. For example:
VAR=$(grep "^something=" <$SBOPKG_RENAMES) some stuff here foo |
if [[ -z $VAR ]]; then bar
and instead of:
if [[ $DIAG ]]; then some stuff here foo \
| bar
* For indices, use FILE and DIR instead of 'f' and 'd'. However, 'i' is OK as when possible.
a counter since that is fairly universal.
* When deciding whether or not to use the =~ operator in [[ commands, make * Always use $( ... ) instead of ` ... `.
sure that they work across bash 3.1, 3.2, and 4.0. This means the regexes
must be unquoted for bash >=3.2 and still work in bash 3.1 (i.e., no
'foo|bar' expressions).
---------------------------- * 'Break' and 'continue' should never be used to influence a loop
Manual Page Style Guidelines outside of the function they belong to.
----------------------------
* Separate all text header and section header requests with commented lines of * Avoid indirect recursion (A calls B that calls A).
equal (=) signs. Separate all subsections and tagged paragraphs that serve
as subsections with commented lines of minus (-) signs.
* Leave no blank lines in the file. E.g., .PP will often serve under .SH and * [[ -z "$VAR" ]] vs. [[ ! "$VAR" ]] and [[ "$VAR" ]] vs.
.IP under .TP. [[ -n "$VAR" ]]: -n/-z should be used when $VAR contains a
computational result and the other form should be used where $VAR
is a functional flag. For example:
* Wrap lines at 72 columns and begin all sentences on new lines. VAR=$(grep "^something=" <$SBOPKG_RENAMES)
if [[ -z $VAR ]]; then
* If variables are being used in the sense of their value, use $VAL but if and
they are being used in reference to themselves, use VAR.
* Where sensible, try to make .TPs have a consistent indent. if [[ $DIAG ]]; then
* Try to use standard headers where possible, filing other information * For indices, use FILE and DIR instead of 'f' and 'd'. However, 'i'
under subsections of the relevant section header. is OK as a counter since that is fairly universal.
* Add options as .TP 5 (or current default), with \- and bold options, * When deciding whether or not to use the =~ operator in [[
followed by italic replaceable arguments to those options or bold literal commands, make sure that they work across bash 3.1, 3.2, and 4.0.
arguments, if any. Brackets, bars, etc., should be regular font, though. This means the regexes must be unquoted for bash >=3.2 and still
work in bash 3.1 (i.e., no 'foo|bar' expressions).
* More generally, italicize filenames, URLs, replaceable terms (including MANUAL PAGE STYLE GUIDELINES
references to unspecified variable values ($VARs)).
* Embolden variables (when used literally rather than replaceably), option * Separate all text header and section header requests with
values, programs, program flags, and all references to sbopkg itself. commented lines of equal (=) signs. Separate all subsections and
tagged paragraphs that serve as subsections with commented lines
of minus (-) signs.
* Make all option dashes in the form \- (or \-\-) unless in a code example. * Leave no blank lines in the file. E.g., .PP will often serve under
.SH and .IP under .TP.
* Try to refer to the user as 'the user' rather than 'you'. * Wrap lines at 72 columns and begin all sentences on new lines.
* Collect all referenced programs (unless used purely as an example) in the * If variables are being used in the sense of their value, use $VAL
SEE ALSO section. (The SEE ALSO section is not *limited* to referenced but if they are being used in reference to themselves, use VAR.
programs, however.)
* Try to be as specific as conveniently possible, where 'convenient' means to * Where sensible, try to make .TPs have a consistent indent.
generalize wherever constant updates might be necessary and such
generalization wouldn't compromise clarity and accuracy.
* Use `` and '' for double-quotes so groff does the fancy stuff for ps output. * Try to use standard headers where possible, filing other
information under subsections of the relevant section header.
* .EX doesn't seem to be very well supported or necessarily what is wanted - * Add options as .TP 5 (or current default), with \- and bold
code examples can be done with the following cookie-cutter code: options, followed by italic replaceable arguments to those options
.RS or bold literal arguments, if any. Brackets, bars, etc., should be
.IP \" or .PP or whatever's appropriate regular font, though.
.nf
\fCline_of_code\fP
.fi
.RE
If inline, at least embolden them so they're set off in ascii overstrike
output.
In command line examples, prefix the commands with the root prompt (#). * More generally, italicize filenames, URLs, replaceable terms
(including references to unspecified variable values ($VARs)).
* Start configuration file option sections with a statement of type, a * Embolden variables (when used literally rather than replaceably),
description, and the following cookie-cutter code: option values, programs, program flags, and all references to
The default assignment is: sbopkg itself.
.IP
\fCdefault_assignment\fP
* Try to refer to SlackBuilds as SlackBuilds rather than SlackBuild scripts * Make all option dashes in the form \- (or \-\-) unless in a code
unless for a particular need (for instance, explaining what SlackBuilds are example.
in the first place). And once SlackBuilds.org has been properly introduced,
try to refer to it as SBo. * Try to refer to the user as 'the user' rather than 'you'.
* Collect all referenced programs (unless used purely as an example)
in the SEE ALSO section. (The SEE ALSO section is not *limited* to
referenced programs, however.)
* Try to be as specific as conveniently possible, where 'convenient'
means to generalize wherever constant updates might be necessary
and such generalization wouldn't compromise clarity and accuracy.
* Use `` and '' for double-quotes so groff does the fancy stuff for
ps output.
* .EX doesn't seem to be very well supported or necessarily what is
wanted - code examples can be done with the following
cookie-cutter code:
.RS
.IP \" or .PP or whatever's appropriate
.nf
\fCline_of_code\fP
.fi
.RE
If inline, at least embolden them so they're set off in ascii
overstrike output.
In command line examples, prefix the commands with the root prompt
(#).
* Start configuration file option sections with a statement of type,
a description, and the following cookie-cutter code:
The default assignment is:
.IP
\fCxxxVARxxx\fP
('xxxVARxxx' will be replaced by whatever value VAR has in the
default sbopkg.conf file.)
* Try to refer to SlackBuilds as SlackBuilds rather than SlackBuild
scripts unless for a particular need (for instance, explaining
what SlackBuilds are in the first place). And once SlackBuilds.org
has been properly introduced, try to refer to it as SBo.

85
src/usr/doc/KNOWN_ISSUES
View File

@ -1,60 +1,67 @@
The following are the known user-visible issues in sbopkg or upstream in the SBOPKG KNOWN ISSUES
tools it uses:
* in dialog '--inputbox' widgets (the boxes the user types text into) the The following are the known user-visible issues in sbopkg or upstream in
left/right arrows do not navigate in a button context. (They do navigate in the tools it uses:
an editing context.) This does not seem to be an sbopkg issue.
Workaround: navigate with up/down arrows or tab/shift-tab * In dialog '--inputbox' widgets (the boxes the user types text into)
Note: there is a newer dialog version available which fixes this issue, but the left/right arrows do not navigate in a button context. (They do
we encourage users to stick with the dialog Slackware ships. navigate in an editing context.) This does not seem to be an sbopkg
issue.
* if dialog is run in a terminal emulator and the user exits using the Workaround: navigate with up/down arrows or tab/shift-tab Note: there
window manager's 'close' (or equivalent) button/command, dialog may hang, is a newer dialog version available which fixes this issue, but we
using full CPU capacity and have to be killed. This does not seem to be an encourage users to stick with the dialog Slackware ships.
sbopkg issue.
* If dialog is run in a terminal emulator and the user exits using the
window manager's 'close' (or equivalent) button/command, dialog may
hang, using full CPU capacity and have to be killed. This does not
seem to be an sbopkg issue.
Details: http://code.google.com/p/sbopkg/issues/detail?id=30 Details: http://code.google.com/p/sbopkg/issues/detail?id=30
Workaround: use dialog's own exit methods - its buttons, escape, ^C, etc. Workaround: use dialog's own exit methods - its buttons, escape, ^C,
etc.
* when checking for updates, for some packages sbopkg may tell you * When checking for updates, for some packages sbopkg may tell you
"Note: repo version not obtainable by standard method, may be inaccurate.". "Note: repo version not obtainable by standard method, may be
This happens with packages whose version is very difficult/impossible to inaccurate.". This happens with packages whose version is very
determine without actually building the package -- one example of this at difficult/impossible to determine without actually building the
the time of writing is the google-chrome package, whose version is picked package -- one example of this at the time of writing is the
from the source archive itself. In these cases sbopkg falls back to trusting google-chrome package, whose version is picked from the source archive
the .info file, and warns the user about it. itself. In these cases sbopkg falls back to trusting the .info file,
and warns the user about it.
Workaround: none needed Workaround: none needed
* while you are free to set PAGER to any value you like, be aware that some * While you are free to set PAGER to any value you like, be aware that
pagers and settings may cause unexpected behavior. An example is if paging some pagers and settings may cause unexpected behavior. An example is
less than a screenful of output from the uninstalled packages option - the if paging less than a screenful of output from the uninstalled
default pager 'more' will exit, displaying the packages and a prompt. 'less' packages option - the default pager 'more' will exit, displaying the
may prompt for exit and clear its output on exit. Setting the environment packages and a prompt. 'less' may prompt for exit and clear its output
variable LESS to include the F and X options will make less behave more like on exit. Setting the environment variable LESS to include the F and X
more in this instance. Other pagers may have other behaviors and other means options will make less behave more like more in this instance. Other
of configuration. pagers may have other behaviors and other means of configuration.
Workaround: pager-specific Workaround: pager-specific
* a few SlackBuild scripts in the slackbuilds.org repo have a source download * A few SlackBuild scripts in the slackbuilds.org repo have a source
that is only available through an https download. By default, sbopkg will download that is only available through an https download. By
not be able to download these sources. default, sbopkg will not be able to download these sources.
Workaround: add --no-check-certificate to WGETFLAGS in sbopkg.conf Workaround: add --no-check-certificate to WGETFLAGS in sbopkg.conf
* certain packages build kernel modules and need to (re)set the ARCH to 'x86' * Certain packages build kernel modules and need to (re)set the ARCH to
on i?86 (32-bit) systems which may result in packages with 'x86' as the ARCH 'x86' on i?86 (32-bit) systems which may result in packages with 'x86'
in the file name, while sbopkg will display the specific ARCH of your system as the ARCH in the file name, while sbopkg will display the specific
(or the ARCH you've set) in certain cases, such as in widget titles. ARCH of your system (or the ARCH you've set) in certain cases, such as
in widget titles.
Workaround: none needed Workaround: none needed
* when using sbopkg to sync to SBo git repositories (which is possible but * When using sbopkg to sync to SBo git repositories (which is possible
unsupported) unexpected results may occur. See but unsupported) unexpected results may occur.
http://code.google.com/p/sbopkg/issues/detail?id=47
http://sbopkg.org/pipermail/sbopkg-users/2010-May/000477.html Details: http://code.google.com/p/sbopkg/issues/detail?id=47
http://sbopkg.org/pipermail/sbopkg-users/2010-May/000477.html
Workaround: see above links Workaround: see above links

2026
src/usr/doc/NEWS
View File

File diff suppressed because it is too large Load Diff

127
src/usr/doc/README
View File

@ -1,64 +1,89 @@
# $Id$ SBOPKG README
# vim:set ft=:
Sbopkg README SBOPKG COPYRIGHT/LICENSE
Copyright 2007-2010 Chess Griffin <chess@chessgriffin.com>
Copyright 2009-2010 Mauro Giachero <mauro.giachero@gmail.com>
slakmagik <slakmagik@gmail.com>
Homepage: http://www.sbopkg.org Copyright 2007-2010 Chess Griffin <chess@chessgriffin.com>
Copyright 2009-2010 Mauro Giachero <mauro.giachero@gmail.com>
slakmagik <slakmagik@gmail.com>
Sbopkg is released under a one-clause BSD license. See the script
itself for the text.
ABOUT ABOUT
Sbopkg (pronounced s-b-o-package) is a command-line and dialog-based tool to Sbopkg (pronounced 's-b-o-package') is a command-line and
synchronize with the SlackBuilds.org ("SBo") repository, a collection of menu-based tool to synchronize with the SlackBuilds.org ('SBo')
third-party SlackBuild scripts to build Slackware packages. Sbopkg can also repository, a collection of third-party SlackBuild scripts to build
synchronize with certain third-party repositories or access a Slackware packages. Sbopkg can also synchronize with any repository
locally-maintained repository. with an SBo-compatible hierarchy, including a locally-maintained
repository.
Sbopkg will allow the user to create, synchronize, search, and browse a copy Sbopkg will allow the user to create, synchronize, search, and
of the active repository (currently, the size of a local copy of the SBo browse a copy of the active repository (currently, the size of a
repository is xxxSIZExxx), read the ChangeLog (if available), list the local copy of the SBo repository is xxxSIZExxx), read the ChangeLog
installed SBo packages, display potential updates to SlackBuilds.org packages, (if available), list the installed SBo packages, display potential
view the README, SlackBuild, .info, and slack-desc files for each package, and updates to SlackBuilds.org packages, view the README, SlackBuild,
make manual edits to a copy of the original .info or SlackBuild files. Sbopkg .info, and slack-desc and other files for each package, and make
will also allow the user to select packages to build and it will download the manual edits to a copy of the original .info or SlackBuild files.
source code, check the md5sum, build a Slackware package, and, optionally Sbopkg will also allow the user to select packages to build and it
install the package. The user can also build, and optionally install, more will download the source code, check the md5sum, build a Slackware
than one package by using the 'build queue' feature. Sbopkg will not check package, and optionally install the package. The user can also build
dependencies since that is not a feature native to Slackware, but since the and optionally install more than one package by using the 'build
build queue will process packages in the order listed, it sometimes may be queue' feature. Sbopkg will not check dependencies since that is not
possible to build and install dependencies in order prior to building and a feature native to Slackware, but since the build queue will
installing the final, desired package. Given the nature of building process packages in the order listed, it is possible to build and
dependencies, however, this probably will not always work and is not really a install dependencies in order prior to building and installing the
supported feature. Ultimately, Sbopkg is one thing and one thing only: a final, desired package.
medium to easily browse a local copy of the SlackBuilds.org and certain other
repositories and build packages from them.
Sbopkg can be also be used strictly from the command line without the Sbopkg can also be used strictly from the command line without the
dialog interface to do most of the above items. Typing sbopkg -h dialog(1)-provided menu interface to do most of the above items.
will display the command line options. Typing 'sbopkg -h' will display the command line options.
HELP HELP
Sbopkg comes with two man pages: sbopkg.conf(5) and sbopkg(8). These Sbopkg comes with two man pages: sbopkg.conf(5) and sbopkg(8). These
man pages are kept up-to-date with functional changes in the script are the primary sources of information on how to use sbopkg.
itself, so they are a good source of information on how to use sbopkg.
If the man pages are not sufficient, please consider joining the sbopkg If you have read the manuals and still need help, you may want to
mailing list and posting your question there. You should be able to join the sbopkg mailing list. Subscribe by sending a mail whose body
subscribe by sending mail to sbopkg-users-request@sbopkg.org whose body is "subscribe your-email@address-here" to:
is 'subscribe your-email@address-here'. There is also an IRC channel for
sbopkg on Freenode at #sbopkg. Further information on all of these
resources is on the project's website at http://www.sbopkg.org - click
the "Docs/Help" tab.
CONTRIBUTORS sbopkg-users-request@sbopkg.org
We welcome bug reports, suggestions, patches, or feature requests. or use the web interface:
Please post any of these to the Issue tracker (kind of like a
Bugzilla) on the project's Google page (click the Issues tab) at http://sbopkg.org/mailman/listinfo/sbopkg-users
http://code.google.com/p/sbopkg so we can keep track of them. There
have been many contributors so far, and they are all mentioned near There is also an IRC channel for sbopkg on Freenode at #sbopkg.
the top of the sbopkg script itself. Thanks to everyone who has
helped make this script better. Further information on these and other resources is on the project
website:
http://sbopkg.org
Specifically, the documentation page is:
http://sbopkg.org/docs.php
CONTRIBUTING
We welcome bug reports, suggestions/feature requests, and patches.
Please post any of these to the issue tracker:
http://code.google.com/p/sbopkg/issues/list
Before reporting a bug, please check the KNOWN_ISSUES file. Before
contributing a suggestion please check the TODO file. Before
submitting a patch, please read the HACKING file.
Sbopkg's source is available in an svn repository hosted on
googlecode. To view a copy of the repo, see:
http://code.google.com/p/sbopkg/source/browse/
To obtain a local copy, use something like the following command:
svn checkout http://sbopkg.googlecode.com/svn/trunk/ sbopkg-contrib
There have been many contributors so far (see the THANKS file).
Thanks to everyone who has helped make this script better.

129
src/usr/doc/README-queuefiles
View File

@ -1,80 +1,91 @@
# $Id$ README-queuefiles
# vim:set ft=:
Sbopkg queuefiles are very simple to create, maintain, and share amongst other Sbopkg queuefiles are very simple to create, maintain, and share amongst
users. Each queuefile can contain a list of applications to build in order, other users. Each queuefile can contain a list of packages to build in
from top to bottom, and should be named with a .sqf extension. Several sample order, from top to bottom, and should be named with a .sqf extension.
queuefiles are provided in the /doc/queuefiles directory. Please note that Several sample queuefiles are provided in the /doc/queuefiles directory.
these queuefiles are, in fact, only samples and have not necessarily been Please note that these queuefiles are, in fact, only samples and have
tested on the latest release of Slackware or on Slackware -current. Please not necessarily been tested on the latest release of Slackware or on
use at your risk. Additionally, the hope is that user-contributed queues can Slackware -current. If you wish to use these at your own risk, remove
be shared. Please consider sending a copy of your queuefile to the sbopkg the '.sample' extension and either put them in QUEUEDIR or set QUEUEDIR
mailing list located at: http://sbopkg.org/mailman/listinfo/sbopkg-users. to where they are (see sbopkg.conf(5) for details). Additionally, the
hope is that user-contributed queues can be shared. Please consider
sending a copy of your queuefile(s) to the sbopkg mailing list located
at http://sbopkg.org/mailman/listinfo/sbopkg-users.
1. Selecting ON or OFF in dialog: SELECTING ON OR OFF IN DIALOG
If the application's name is left alone, it will default to 'ON,' or If a line starts with an application's name, it will default to 'ON'
selected, in the sbopkg dialog menus when the queuefile is loaded. If and be selected in the sbopkg dialog menus when the queuefile is
the application's name is prepended with a '-' it will default to loaded. If the application's name is prepended with a '-' it will
'OFF,' or deselected, in the dialog menus. default to 'OFF' and be deselected in the dialog menus.
For example, a queuefile might contain: For example, a queuefile might contain:
foo foo
-bar -bar
baz baz
In this case, both 'foo' and 'baz' will appear 'ON,' or selected, in the sbopkg In this case, both 'foo' and 'baz' will be 'ON' and appear selected
dialog menus, and 'bar' will appear 'OFF,' or deselected. in the sbopkg dialog menus, and 'bar' will be 'OFF' and appear
deselected.
2. Recursive queuefiles: RECURSIVE QUEUEFILES
Additionally, queuefiles may be loaded recursively. This means the user can Additionally, queuefiles may be loaded recursively. This means the
have separate queuefiles for certain applications, or certain queues, and then user can have separate queuefiles for certain applications, or
a 'master' queuefile can bring them all together. Recursively-loaded queues certain queues, and then a 'master' queuefile can bring them all
are indicated by a '@' prepended to the name of the queuefile. together. Recursively-loaded queues are indicated by an '@'
prepended to the name of the queuefile.
For example, a user might have one queuefile named 'multimedia.sqf' with these For example, a user might have one queuefile named 'multimedia.sqf'
items: with these items:
app1 app1
app2 app2
app3 app3
And then the user might have another queuefile named 'mydesktop.sqf' with And then the user might have another queuefile named 'mydesktop.sqf'
these items: with these items:
app4 app4
app5 app5
@multimedia.sqf @multimedia.sqf
In this case, when the 'mydesktop.sqf' queuefile is loaded, it will first load In this case, when the 'mydesktop.sqf' queuefile is loaded, it will
app4, then app5, then the contents of the multimedia.sqf queuefile. The final first load app4, then app5, then the contents of the multimedia.sqf
queue will look like this: queuefile. The final queue will look like this:
app4 app4
app5 app5
app1 app1
app2 app2
app3 app3
3. Passing build options: (Note that, while a given queuefile must have the .sqf extension to
be loaded, the extension is optional within queuefiles. For
instance, if multimedia.sqf exists in the QUEUEDIR, '@multimedia'
would work in the above example.)
Finally, it is possible to pass build options for an application in a PASSING BUILD OPTIONS
queuefile. This is done by using a single pipe ('|') character after the
application name. For example:
app | FOO=yes BAR=no Finally, it is possible to pass build options for an application in
a queuefile. This is done by using a single pipe ('|') character
after the application name (spaces are optional). For example:
Only use one pipe to separate the application name and the variables. app | FOO=yes BAR=no
In case the user has saved build options individually in the dialog interface, Only use one pipe to separate the application name and the
and also puts build options for that same application in the queuefile, sbopkg variables.
will ask the user which one should be used.
4. Multiple instances. In case the user has saved build options individually in the dialog
interface, and also puts build options for that same application in
the queuefile, sbopkg will ask the user which one should be used.
In all cases, whether loading software names more than once, or indicating DUPLICATE BUILDS/OPTIONS
build options in more than one queuefile, the first instance will apply. So
if a user has "app" in one queuefile, and "-app" in a recursive queuefile that In all cases, whether loading software names more than once, or
is loaded further down the list, the first instance, or "app" will prevail. indicating build options in more than one queuefile, the first
instance will apply. So if a user has "app" in one queuefile, and
"-app" in a recursive queuefile that is loaded further down the
list, the first instance, or "app" will prevail.

28
src/usr/doc/README-renames.d
View File

@ -1,14 +1,20 @@
# $Id$ README-renames.d
# vim:set ft=:
The /etc/sbopkg/renames.d directory is the directory that holds files The /etc/sbopkg/renames.d directory is the directory that holds files
associated with renamed software in the SlackBuilds.org repository. The associated with renamed software in the SlackBuilds.org repository.
default file that is installed with sbopkg is '50-default'. This file will be
overwritten each time sbopkg is upgraded, so do not make local edits to it. Renames are written, one per line, in the following format:
Instead, create other files with a higher or lower number than 50-default and
list your renamed files in those local files. The files are loaded in oldname=newname
alphabetical order (like the files in /etc/fonts/conf.d) so 'priority'
is determined from low number to high and the first match wins, so: The default file that is installed with sbopkg is '50-default'. This
file will be overwritten each time sbopkg is upgraded, so do not make
local edits to it. Instead, create other files with a higher or lower
number than 50-default and list your renamed files in those local files.
The files are loaded in alphabetical order (like the files in, e.g.,
/etc/fonts/conf.d) so 'priority' is determined from low number to high
and the first match wins, so:
$ cat /etc/sbopkg/renames.d/10-local $ cat /etc/sbopkg/renames.d/10-local
foo=bar foo=bar
@ -18,7 +24,3 @@ will override anything in a higher-numbered file, including anything in
$ cat /etc/sbopkg/renames.d/50-default $ cat /etc/sbopkg/renames.d/50-default
foo=baz foo=baz
Renames are written in the following format:
oldname=newname

81
src/usr/doc/README-repos.d
View File

@ -1,40 +1,49 @@
# $Id$ README-repos.d
# vim:set ft=:
In sbopkg parlance, a "repository" is a local or remote service used as a In sbopkg parlance, a "repository" is a local or remote service used as
source of scripts. For example, slackbuilds.org is a repository. The a source of SlackBuilds. For example, slackbuilds.org is a repository.
builds.slamd64.com project is another repository. Every repository has one or The builds.slamd64.com project is another repository. Every repository
more "branches". Branches consist of a single tree of scripts. For example, has one or more "branches". Branches consist of a single tree of scripts
slackbuilds.org has a 11.0 branch, a 12.0 branch and so on. in a category/application hierarchy. For example, slackbuilds.org has a
11.0 branch, a 12.0 branch and so on.
/etc/sbopkg/repos.d is a directory containing files defining the /etc/sbopkg/repos.d is a directory containing files defining the
sbopkg-supported repositories and branches. All *.repo files are scanned in repositories and branches sbopkg will use. All *.repo files are scanned
alphabetical order. Every line in a *.repo file defines a branch. Each line in alphabetical order. Every line in a *.repo file defines a branch
is compound of the following seven fields: except those _containing_ a '#' which are ignored. Lines containing
1. REPOSITORY (a _short_ name identifying the repository)
2. BRANCH (a _short_ name identifying the branch of that repository)
3. DESCRIPTION (a <50 chars description, which _must_be_quoted_)
4. TAG (the packages' tag)
5. TOOL (rsync, git or "", is the tool able to check out the repository/branch)
6. LINK (the tool-dependent link to the branch)
7. CHECKGPG (whether the repo provides .asc signature files and signed
tarballs that can be verified with GPG)
For example, one branch (line) of the sbo.repo file might look like this (note
the seven fields):
SBo 12.2 "SBo repository for Slackware 12.2" _SBo rsync slackbuilds.org::slackbuilds/12.2 GPG
If TOOL is set to "", then it will not be possible to automatically update the
branch (i.e., it has no upstream). This is most commonly used for
locally-maintained repositories on the host filesystem that do not use rsync
or git to pull down the repository tree. The LINK format is essentially what
is required to be passed to the specified TOOL. In case of git links, it
_must_ be in the form url@branch. If TOOL is "", LINK is ignored (but _must_
still be present). CHECKGPG format can be "GPG" if the repo supports GPG
checking, or "" (which also must be present) if the repo does not support GPG
checks.
Lines _containing_ # are ignored when parsing the files. Lines containing
backslashes (\) are not allowed. backslashes (\) are not allowed.
Each line contains the following seven fields (if a field is not
applicable, it still _must_ be present in the form of an empty quote
(""):
1. REPO
A _short_ name identifying the repository; e.g., 'SBo'.
2. BRANCH
A _short_ name identifying the branch of that repository; e.g.,
'11.0'.
3. DESCRIPTION
A description of the repo, which _must be quoted_ and must be less
than 50 characters long; e.g., '"SBo repository for Slackware
11.0"'.
4. TAG
The tag the built packages will have; e.g., '_SBo'.
5. TOOL
The tools used to download the repository/branch. The currently
supported value is 'rsync'. Using 'git' is also possible. Local
repos will have an empty quote. If this field is an empty quote, it
will not be possible to automatically update the branch (i.e., it
has no upstream).
6. LINK
The link (URL) to the branch that the TOOL will use. Local repos
will have an empty quote. In the case of git links, it _must_ be in
the form url@branch.
7. CHECKGPG
Filled with 'GPG' if the repo provides .asc signature files and
signed tarballs that can be verified with GPG, and an empty quote
otherwise.
For example, one branch (line) of the sbo.repo file looks like this
(note the seven fields):
SBo 11.0 "SBo repository for Slackware 11.0" _SBo rsync slackbuilds.org::slackbuilds/11.0 GPG

71
src/usr/doc/THANKS Normal file
View File

@ -0,0 +1,71 @@
SBOPKG THANKS
The following people have contributed to the development of sbopkg. They
are generally listed by the revision number the effect of their first
contribution entered the trunk, followed by their alternate name(s) (if
any), and the type(s) of contributions. This script would not be where
it is without the help of these folks. If we left anyone out, we
apologize. Thank you!
1 Chess Griffin (project initiation, bug reports, suggestions, code)
14 Bob Lounsbury (suggestion)
14 Robby Workman (suggestion)
14 Alan Hicks (suggestion)
14 Paul Wisehart (suggestion
14 Phillip Warner (bug reports, suggestion)
14 slakmagik (bug reports, suggestions, code)
?? Eric Hameleers (?,code)
?? Michiel van Wessem (?)
30 hba (patch)
77 Erik Hanson (suggestions, patches)
?? Antoine (bug report)
97 ktabic (bug report)
97 Ken Roberts (bug report)
120 samac (bug report)
122 Bert Babington (patch)
123 Murat D. Kadirov [banderols] (suggestion)
157 The-spiki (bug report, suggestion)
160 David Somero (bug report)
174 LukenShiro (bug reports)
182 Drew Ames (bug report, suggestion)
186 nille (suggestion)
192 acidchild (bug report)
??? mancha (?)
194 macavity (patch, suggestion)
197 Zordrak (suggestion)
201 Joao Felipe Santos (bug report)
205 Jorge Gaton (bug report)
213 cotterochan (bug report)
228 necropresto (bug report)
230 Pierre Cazenave (bug report)
257 Mauro Giachero (bug reports, suggestions, code)
259 The-Croupier (suggestion)
282 Wade Grant (bug report)
283 SpacePlod (bug report)
389 TSquaredF (suggestion)
398 alkos333 (suggestion, code)
418 Gregory Tourte [artourter] (bug reports, suggestions)
464 Marie-Claude Collilieux (translations)
534 Glenn Becker (bug reports)
534 jturning (bug report)
584 David Spencer (bug reports; testing fix)
641 NaCl (bug report)
661 neonflux (bug report)
673 Marco Bonetti (suggestion)
696 dive (suggestion)
700 idknow (bug report)
706 slackhead (bug report)
716 happyslacker (suggestion)
720 pokipoki08 (suggestion)
723 SiegeX (bug report and suggestions)
723 Zmyrgel (bug report and suggestions)
723 BCarey (bug report and suggestions)
735 godling (bug report)
748 Matteo Bernardini (suggestion)
757 agikhan (suggestion)
770 slava18 (bug reports)
772 skalkoto (bug report)
828 Marc Payne (confirming bug report)
847 catkin (bug report)
849 chytraeus (bug report)
850 greinze (bug report)

54
src/usr/doc/TODO
View File

@ -1,27 +1,29 @@
# $Id$ SBOPKG TODO
# vim:set ft=:
Sbopkg TODO (in no particular order) Items should be grouped by {High,Medium,Low} Priorities with sub-groups
* Add in better traps and error checks so a user can safely exit (by pressing of {Feature,Modification,Bugfix} Categories.
Control-C) during the source download or during the package building
process. I have spent a _lot_ of time hacking on this but have not come up MEDIUM PRIORITY
with a workable solution yet. The problem is that many subprocesses are
forked off during the package building process and it's difficult to capture Feature Category
all the pids. If anyone wants to help with this, please let me know.
of sbopkg 0.26.0. * Allow lftp as a sync method.
* Include a way to change the sync from rsync to lftp for those who have rsync
blocked. Modification Category
* Figure out proper way of testing getopts in order to prevent certain cli
options from being used together, such as -b and -i. Right now, there is a * Properly test supplied options to ensure that only sensible
crude test to prevent -b and -i from being used together, but I know there option combinations are allowed, thus replacing the current
is a better way. crude test which only prevents -b and -i from being used
* Add 'long' switches to the cli options, i.e. --build in addition to the together.
current -b switch. This is pretty low priority, IMHO, and something tells
me that getopts does not like long options anyway. LOW PRIORITY
* Maybe change all instances of 'dialog' to $DIALOG and set $DIALOG to be a
variable equal to either 'dialog' or 'xdialog' in case someone wanted to run Feature Category
sbopkg using xdialog. I don't know how compatible dialog is with xdialog so
if there was breakage, I would not want to really address it as being able * Replace getopts call with custom option parsing and add 'long'
to use xdialog is not important to me. I prefer dialog anyway. switches to the cli options (for example, '--build' in
* More error checking. addition to the current '-b' switch).
* General code cleanups.
* Replace all calls to dialog with a DIALOG variable (which
would still default to dialog), allowing users to more easily
try other interfaces.

0
src/usr/doc/queuefiles/abiword.sqf → src/usr/doc/queuefiles/abiword.sqf.sample
View File

0
src/usr/doc/queuefiles/audacity.sqf → src/usr/doc/queuefiles/audacity.sqf.sample
View File

2
src/usr/doc/queuefiles/dvdrip_build.sqf → src/usr/doc/queuefiles/dvdrip_build.sqf.sample
View File

@ -11,7 +11,7 @@ perl-event
perl-libintl perl-libintl
lsdvd lsdvd
# mplayer is available in /extra for current/13.0 # mplayer is available in /extra for current/13.0
# You may wish to recompile it to include the ability to read # You may wish to recompile it to include the ability to read
# encrypted DVDs though. See its SlackBuild for more info. # encrypted DVDs though. See its SlackBuild for more info.
-mplayer -mplayer
ogmtools ogmtools

0
src/usr/doc/queuefiles/enlightenment.sqf → src/usr/doc/queuefiles/enlightenment.sqf.sample
View File

0
src/usr/doc/queuefiles/ffmpeg.sqf → src/usr/doc/queuefiles/ffmpeg.sqf.sample
View File

0
src/usr/doc/queuefiles/ffmpeg_build.sqf → src/usr/doc/queuefiles/ffmpeg_build.sqf.sample
View File

0
src/usr/doc/queuefiles/gnome-print.sqf → src/usr/doc/queuefiles/gnome-print.sqf.sample
View File

0
src/usr/doc/queuefiles/gnucash.sqf → src/usr/doc/queuefiles/gnucash.sqf.sample
View File

0
src/usr/doc/queuefiles/gpodder.sqf → src/usr/doc/queuefiles/gpodder.sqf.sample
View File

2
src/usr/doc/queuefiles/mlt-openshot.sqf → src/usr/doc/queuefiles/mlt-openshot.sqf.sample
View File

@ -6,4 +6,4 @@ libdv
libsamplerate libsamplerate
@ffmpeg.sqf @ffmpeg.sqf
libquicktime libquicktime
mlt mlt

0
src/usr/doc/queuefiles/multimedia.sqf → src/usr/doc/queuefiles/multimedia.sqf.sample
View File

0
src/usr/doc/queuefiles/octave_build.sqf → src/usr/doc/queuefiles/octave_build.sqf.sample
View File

0
src/usr/doc/queuefiles/openbox-plus.sqf → src/usr/doc/queuefiles/openbox-plus.sqf.sample
View File

4
src/usr/doc/queuefiles/openshot.sqf → src/usr/doc/queuefiles/openshot.sqf.sample
View File

@ -5,11 +5,11 @@
# /var/lib/sbopkg/queues directory # /var/lib/sbopkg/queues directory
# openshot.sqf # openshot.sqf
# mlt-openshot.sqf # mlt-openshot.sqf
# #
@mlt-openshot.sqf @mlt-openshot.sqf
frei0r frei0r
goocanvas goocanvas
pygoocanvas pygoocanvas
pyxdg pyxdg
openshot openshot

0
src/usr/doc/queuefiles/simple-desktop.sqf → src/usr/doc/queuefiles/simple-desktop.sqf.sample
View File

0
src/usr/doc/queuefiles/transcode_build.sqf → src/usr/doc/queuefiles/transcode_build.sqf.sample
View File

15
src/usr/sbin/sbopkg
View File

@ -23,21 +23,6 @@
# LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING # LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
# NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS # NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
# SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. # SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
#
# Slackware is a registered trademark of Patrick Volkerding.
# Linux is a registered trademark of Linus Torvalds.
#
# Other contributors: Bob Lounsbury, Robby Workman, Alan Hicks, Paul
# Wisehart, slakmagik, Eric Hameleers, Michiel van Wessem, hba, Erik Hanson,
# Antoine, ktabic, Ken Roberts, samac, Bert Babington, Murat D. Kadirov,
# The-spiki, David Somero, LukenShiro, Drew Ames, nille, acidchild, mancha,
# macavity, Zordrak, João Felipe Santos, cotterochan, necropresto, Pierre
# Cazenave, Mauro Giachero, The-Croupier, Wade Grant, TSquaredF, alkos333,
# Marco Bonetti and Gregory Tourte.
# This script would not be where it is without the help of these folks.
# If I left anyone out, I apologize. Thank you!
#
#set -x
dialog_refresh_workaround() { dialog_refresh_workaround() {
# Dialog has refresh problems on some terminals (currently known are some # Dialog has refresh problems on some terminals (currently known are some