update some of the items in /docs

src/usr/doc/README

@@ -8,27 +8,28 @@ Homepage:  http://www.sbopkg.org
 ABOUT
 
 Sbopkg is a command-line and dialog-based tool to synchronize with the
-SlackBuilds.org ("SBo") repository, a collection of third-party
-SlackBuild scripts to build Slackware packages.  Sbopkg will allow the
-user to create, synchronize, search, and browse a local copy of the
-SBo repository (currently, the size of a local copy of the SBo
-repository is less than 50MB), read the ChangeLog, list the installed
-SBo packages, display potential updates to SlackBuilds.org packages,
-view the README, SlackBuild, .info, and slack-desc files for each
-package, and make manual edits to a copy of the original .info or
-SlackBuild files.  Sbopkg will also allow the user to select packages
-to build and it will download the source code, check the md5sum, build
-a Slackware package, and, optionally install the package.  The user
-can also build, and optionally install, more than one package by using
-the 'build queue' feature.  Sbopkg will not check dependencies since
-that is not a feature native to Slackware, but since the build queue
-will process packages in the order listed, it sometimes may be
-possible to build and install dependencies in order prior to building
-and installing the final, desired package.  Given the nature of
-building dependencies, however, this probably will not always work and
-is not really a supported feature.  Ultimately, Sbopkg is one thing
-and one thing only: a medium to easily browse a local copy of the
-SlackBuilds.org repository and build packages from it.
+SlackBuilds.org ("SBo") repository, a collection of third-party SlackBuild
+scripts to build Slackware packages.  Sbopkg can also synchronize with certain
+third-party repositories or access a locally-maintained repository.
+
+Sbopkg will allow the user to create, synchronize, search, and browse a copy
+of the active repository (currently, the size of a local copy of the SBo
+repository is less than 50MB), read the ChangeLog (if available), list the
+installed SBo packages, display potential updates to SlackBuilds.org packages,
+view the README, SlackBuild, .info, and slack-desc files for each package, and
+make manual edits to a copy of the original .info or SlackBuild files.  Sbopkg
+will also allow the user to select packages to build and it will download the
+source code, check the md5sum, build a Slackware package, and, optionally
+install the package.  The user can also build, and optionally install, more
+than one package by using the 'build queue' feature.  Sbopkg will not check
+dependencies since that is not a feature native to Slackware, but since the
+build queue will process packages in the order listed, it sometimes may be
+possible to build and install dependencies in order prior to building and
+installing the final, desired package.  Given the nature of building
+dependencies, however, this probably will not always work and is not really a
+supported feature.  Ultimately, Sbopkg is one thing and one thing only: a
+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
 dialog interface to do most of the above items.  Typing sbopkg -h

src/usr/doc/README-repos.d

@@ -1,26 +1,33 @@
-In sbopkg documentation and code, a "repository" is a remote service used as
-a source of scripts. For example, slackbuilds.org is a repository.
-Every repository has one or more "branches". Branches consist of a single
-tree of scripts. For example, slackbuilds.org has a 11.0 branch, a 12.0 branch
-and so on.
-The tool-specific code abstracts the differences induced by the use of
-different technologies to provide scripts.
+In sbopkg parlance, a "repository" is a local or remote service used as a
+source of scripts.  For example, slackbuilds.org is a repository.  The
+builds.slamd64.com project is another repository.  Every repository has one or
+more "branches".  Branches consist of a single tree of scripts.  For example,
+slackbuilds.org has a 11.0 branch, a 12.0 branch and so on.
 
-repos.d is a directory containing files defining the sbopkg-supported
-repositories and branches. All *.repo files are scanned in alphabetical order.
-Every line in each file defines a branch. The line is compound of the
-following fields:
-- REPOSITORY (a _short_ name identifying the repository)
-- BRANCH (a _short_ name identifying the branch of that repository)
-- DESCRIPTION (a <50 chars description, which _must_be_double_quoted_)
-- TAG (the packages' tag)
-- TOOL (rsync, git or "", is the tool able to check out the repository/branch)
-- LINK (the tool-dependent link to the branch)
+/etc/sbopkg/repos.d is a directory containing files defining the
+sbopkg-supported repositories and branches.  All *.repo files are scanned in
+alphabetical order.  Every line in a *.repo file defines a branch.  Each line
+is compound of the following six fields:
 
-If TOOL is "", then it won't be possible to automatically update the branch
-(it has no upstream). 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_ be present).
+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_double_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)
 
-Lines _containing_ # are ignored when parsing the files. Lines containing a
-single quote (') or backslashes (\) aren't allowed.
+For example, one branch (line) of the sbo.repo file might look like this (note
+the six fields):
+
+SBo 12.2 "SBo repository for Slackware 12.2" _SBo rsync slackbuilds.org::slackbuilds/12.2
+
+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).
+
+Lines _containing_ # are ignored when parsing the files.  Lines containing a
+single quote (') or backslashes (\) are not allowed.

src/usr/doc/TODO

@@ -7,7 +7,6 @@ Sbopkg TODO (in no particular order)
   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
   all the pids.  If anyone wants to help with this, please let me know.
-* FIX THE UPDATE LIST FEATURE SO THERE IS NO NEED FOR UGLY HACKS! :-)  DONE as
   of sbopkg 0.26.0.
 * Include a way to change the sync from rsync to lftp for those who have rsync
   blocked.
@@ -18,24 +17,12 @@ Sbopkg TODO (in no particular order)
 * Add 'long' switches to the cli options, i.e. --build in addition to the
   current -b switch.  This is pretty low priority, IMHO, and something tells
   me that getopts does not like long options anyway.
-* Perhaps add a way where, if sbopkg is run by non-root user, that it can
-  prompt for the root user's password before building.  I know there is a
-  password type dialog box available, but I have not looked into or, nor have
-  I investigated what it would mean if sbopkg su'd to root to do the 'sh
-  foo.SlackBuild.build'  Maybe it cannot be done safely or correctly.
 * 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
   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
   to use xdialog is not important to me.  I prefer dialog anyway.
 * Perhaps make the MD5SUM check a variable that a user can turn off?
-* When using the dialog interface, change the listing of packages to be a
-  checklist or radiolist whereby the user can select more than one package to
-  build at a time.  This would possibly change how the user would be able to
-  view the README, slack-desc etc. since a checklist or radiolist would not
-  present the current 'view' menu.  Not sure how the order of packages
-  selected would be set.  UPDATE: This is basically done for sbopkg 0.20.0 via
-  the build queue.
 * Maybe find a way to run more than once instance for -b building.
 * More error checking.
 * General code cleanups.