SVN r224656:
Add back ftp4, a new machine has taken its place. ftp2 and ftp8 are both
IPv6 capable mirrors. cvsup4/ftp4 have already been added to the handbook.
NOTE: Except put IPv6 entries in IPv6 section at the top of the list
SVN r225467:
Add ftp4.se.freebsd.org to the IPv4 and IPv6 mirror lists.
SVN r235228:
Add the IPv6 tag to ftp4.fr.freebsd.org.
NOTE: Except dup entry into IPv6 section.
SVN r243832:
- Remove snapshots.se.freebsd.org [1]
- Add ftp6.se.freebsd.org
SVN r243854:
Remove snapshots.jp.freebsd.org. It stopped working years ago.
SVN r253543:
Update mirror list to more closely match
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mirrors-ftp.html
MFC after: 1 week
nfs, ftp, http, httpproxy, etc.) and f_device_get() (abstract method for
calling aforementioned f_media_get_TYPE()).
Previously, if $probe_only was present and non-NULL, the TYPE functions
would check for $file and exit with an appropriate error status (success if
the file exists and readable, failure otherwise).
While this has been retained, a pair of globals has been introduced:
$PROBE_EXIST and $PROBE_SIZE (see `/usr/share/bsdconfig/media/common.subr')
The $PROBE_EXIST global can be used where you need the functionality of
simply testing for existence (previously the _only_ functionality).
Meanwhile, the new $PROBE_SIZE global can be used to cause the TYPE function
to print the size of the file (in bytes) on standard-out (or -1) if not
found or an error occurs. NOTE: If an error occurs, it is logged with the
dprintf function, which is visible with `-d' flag or debug=1.
In many cases, where you need to get the size of a file _and_ check for its
existence, you can use the return status of a $PROBE_SIZE call.
an executable by-name without forking or using externals.
In a performance benchmark of 10,000 runs on circa 2006 hardware, f_which
out-performed `which' with an average completion time of ~2.5 seconds versus
~56 seconds.
This should be handy for future use (not that I make it a habit to call
`which' in a loop 10,000 times).
if it exists to determine if use_shadow is true (ON) or false (OFF).
The purpose of determining the value of use_shadow is to know how many lines
to subtract from the maximum height value in assuring that the backtitle is
not obscured.
The detriment of obscuring the backtitle is that it provides information
that is not easily obtained elsewhere. That is the command-line shortcut
used to access the current menu. As you navigate from one dialog to the
next, invariably transparently corssing module boundaries, the backtitle
represents the command-line argument used to get there. Obscuring this
information with a widget that is too-tall and/or too-wide would see that
data go unnoticed (leaving few other ways to get that information in the
same helpful context).
So despite the fact that this change reduces the standard maximum height for
all widgets, there is a trap-door to prevent this calculation. If you want
to utilize the full screen height on the terminal (remember, this adjustment
is not made for Xdialog(1)) you can set $NO_BACKTITLE to 1 (or any non-NULL
value for that matter) and this calculation will be skipped. You will be
able to draw a widget that partially obscures the backtitle if-necessary.
MFC after: 1 day
(packageReinstall) and UI access have been tested successfully with a
variation of different situations including:
+ Reinstall a package for which no other packages depend
+ Purposefully do thinks like reinstall a package that is not installed
+ Try to reinstall a package which other installed packages still depend
NOTE: There is no "force" used; if a package is required by other packages,
it will not be uninstalled (and therefore no reinstall is done).
(this is designed to allow new modules to be installed via ports/packages).
To prevent conflict with itself (sysutils/bsdconfig) as a port (which
installs its base modules to the above directory, it was long-ago decided
that so-called `base' modules would look different than now-defined `add-on'
modules. The structure of the contents for each is the same, but the naming
convention for the module directory must be different.
Base modules are named `[0-9][0-9][0-9].*' to allow SysV-style organization
while add-on modules must avoid this naming style and are simply listed in
alphabetical order by their module directory.
For example, a hypothetical port named `bsdconfig-jails' could install
/usr/local/libexec/bsdconfig/jails and provide `bsdconfig jails' as well as
a new menu entry in the main-menu.
Add-on modules are listed in the main-menu (when bsdconfig is executed with-
out arguments) below a separator after the last base-module.
In `bsdconfig -h' output, add-on modules are listed right alongside base
modules (sorted alphabetically in columnar fashion; left-to-right).
If a base module declares a keyword used by an add-on module, the base
module will always win when given `bsdconfig keyword' syntax.
Add-on modules should avoid declaring any keyword found in `script.subr' as
a reserved-word (`Resword') since bsdconfig also supports `bsdconfig resword'
as a fall-back if no keyword is found to be declared by any module.
difference between these two functions:
Usage: f_show_msg() $format_string [ $format_args ... ]
Usage: f_dialog_msgbox() $text [ $hline ]
The former lends itself well to displaying the $msg_* i18n text, prompts,
etc. While the latter is better for text you do not control (error strings
captured as a response from external commands) -- or if you have to control
the hline.
Both scripted access (packageDelete) and UI access have been tested
successfully with a variation of different situations including:
+ Uninstall a package which no other installed package depends
+ Uninstall multiple packages which no other installed packages depend
+ Uninstall multiple packages which depend on each other
+ Similar to above but when ordered removal requires tracing dependencies
+ Purposefully do things like uninstall a package that is not installed
+ Try to uninstall a package which other installed packages still depend
+ Try to uninstall multiple packages which other installed packages depend
+ And many more.
because [currently] we exit after performing requests actions -- if we
ever change this to returning to the package selection screen, this would
have made an impact).
sysinstall(8). The UI for this will come later while this exposes the
functionality to the scripted interface. Tested successfully to first
install the pcnfsd package from the `Latest' repository, and second to
configure mountd_flags="-n" in rc.conf(5).
pending). Both scripted access (packageAdd) and UI access have been tested
successfully with a variation of different situations including:
+ Install a package with no dependencies
+ Install a package with dependencies that are already installed
+ Install a package with dependencies where some are already installed
+ Repeat each of the above from FTP and local Directory
+ Purposefully do things like try to install a package that does not exist
+ Try to install a package for which a dependency could not be loaded
+ Try to install a package that is in the INDEX bot not on the media
+ And many more.
