remove UPDATELIST-DEBUGGING; update TODO; remove reference to UPDATELIST-DEBUGGING from sbopkg(8) man page

This commit is contained in:
chess.griffin 2009-01-28 14:49:17 +00:00
parent 4a6a0825e9
commit f80218a292
3 changed files with 35 additions and 92 deletions

View File

@ -1,52 +1,41 @@
# $Id$
Sbopkg TODO (in no particular order)
* Add in better traps and error checks so a user can safely exit (by
pressing 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 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! :-)
This is much easier said than done, IMHO. Simply comparing $VERSION
(or, more accurately, $VERSION plus $BUILD), between the installed
package and the one in the repo is not enough. The reasons are
many, such as the fact that some of the SlackBuild scripts at SBo do
their own thing, such as use other variables (i.e. replace $VERSION
with $SRCVER or something), or include the kernel version in the
package version, such as nvidia-kernel does, or that fail the bash
'decimal' problem ... Anyway, there may be some work on this
already, so please contact me before starting anything.
* Include a way to change the sync from rsync to lftp for those who
have rsync blocked.
* 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 crude test to prevent -b and -i from being used together,
but I know there is a better way.
* 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.
* Add in better traps and error checks so a user can safely exit (by pressing
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
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.
* 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
crude test to prevent -b and -i from being used together, but I know there
is a better way.
* 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.
* 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.

View File

@ -1,44 +0,0 @@
Starting with sbopkg version 0.0.8, there is a feature that displays
potential updates to SBo packages installed on a user's system. This
feature is still a work in progress, and bugs are expected. Most bugs
will manifest themselves as either (a) missing updates -- those
updates that should appear in the list but do not or (b) false
positives -- updates listed in the list that are not really updates at
all. If you run into either of these problems, please do the
following in order to assist me with bug-reporting:
To begin debugging, please edit your sbopkg.conf and change the DEBUG
variable and set it as follows: DEBUG=2.
This variable turns on a more detailed update list. This more
detailed list will list all installed SlackBuilds.org packages, and
will list package updates, packages that have no updates, packages
that are not in the repo, and packages for which the installed version
is newer than the repo version. This variable also saves the update
list as a permanent log, described below.
After this variable has been changed, save the sbopkg.conf file and
rerun sbopkg. Please select the update feature as normal and then
exit sbopkg. The permanent log of the update list will now be saved
in $TMP/sbopkg-debug-updatelist.
Finally, in order to compare this permanent log with the actual list
of installed packages, please do as a root user:
# cd /var/log/packages; ls *SBo* > mypackagelist.txt
Please forward the permanent log and the mypackagelist.txt files to me
via email to chess@chessgriffin.com or post them in the sbopkg mailing
list, which can be found at the project's Google Code page:
http://code.google.com/p/sbopkg.
Once you have forwarded or copied the log and the mypackagelist.txt to
a safe location, feel free to change the DEBUG variable in sbopkg.conf
back to its original setting (the default is 0, but some may have it
set to 1), which will then disable the creation of the permanent
update log, keeping your $TMP clean. Of course, leaving DEBUG=2 is
fine as well and it will create a new $TMP/sbopkg-debug-updatelist
each time the update feature is used as well as display the detailed
update list each time you use the update feature.
Thanks for your help!

View File

@ -73,9 +73,7 @@ will build foo and then bar.
.TP 5
.B -c
Display list of installed SBo packages and potential updates. This is
an experimental feature. Please see UPDATELIST-DEBUGGING in the
sbopkg documentation directory to assist with bug reporting.
Display list of installed SBo packages and potential updates.
.TP 5
.B -d DIRECTORY