Brooktrout SDK Linux Update/Install

Goals

• Simply the process for upgrading an installation under Linux. This request was made by Nexway but will apply to all Linux customers.

Background and strategic fit

Currently there are two packages, sdk_linux.rpm (BRKTBOSsetup) and fw_linux.rpm (BRKTBOSsetup-fw). Combine them into a single package (sdk_linux.rpm) and just one package name (BRKTBOSsetup). (For reference, Solaris has a single package.) This also applies to the non-sr140 versions.

After installation, the config directory contains btcall.cfg, callctrl.cfg, BT_CPARM.CFG, and other files. Identical copies of these files will also be installed into the samples.cfg subdirectory. (There was discussion about using CM Synergy "links", but that is not applicable. This turns out to be an installation/packaging issue, only.)

Change the RPM removal scripts so that they will stop Bostsrv, uninstall the driver, and remove the /etc/startbost script.

Modify the setup.sh installation script as follows:

Add a -remove option to remove any installed package(s).

Add a -y option to automatically proceed without confirmations.

Remove the part where it prompts for whether to install SDK or firmware or both. If no relevant packages are previously installed, it will display information about the version of the package to be installed and prompt whether to proceed with installation (unless prompts skipped).

If the BRKTBOSsetup (and/or BRKTBOSsetup-fw) package is already installed, it will display information about the new and old packages and prompt whether to replace the packages (unless prompts skipped).

If the version of the sdk_linux.rpm is earlier than 6.7.3 then it will look for an fw_linux.rpm and install that, too.

If the package is being replaced, the old /etc/startbost file (or at least the driver parameters embedded within), if it exists, will be saved to a temporary location. The new driver will be initially configured with default parameters. (This can be done by causing a return to be entered at all prompts, so it doesn't require a priori knowledge of what command line options are required.) Then the new /etc/startbost file will be modified so that the original saved driver parameters will replace the new default ones up to the number of saved ones, and any new ones will go afterwards.

Before removing the package, the btcall.cfg, callctrl.cfg, and BT_CPARM.CFG from the config directory will be compared to the ones in config/samples.cfg. If any are different, save them to a temporary location and also save the corresponding config/samples.cfg files. After installing the new package, then restore the files to the config directory. Also compare the saved config/samples.cfg files to those in the new config/samples.cfg directory.  If any of these are different, that means that something changed in the ones supplied with our SDK as well as the ones the user was using, and a warning will be printed.

After the new package is installed, the kernel patch driver rebuild procedure will be checked for, and prompted for if needed (unless prompts skipped). If this fails (e.g., the compiler environment is not installed), a warning will be printed.

The prompt about configuring the driver will be displayed only if the the package and driver were not previously installed. This can also be overridden if prompts are skipped, in which case all defaults will be used.

The check for "bfax" will no longer be performed.

There is currently a very small and unneeded difference between the setup.sh script for the packages that include the SR140 and those that do not. The files will be made identical.

Requirements

User interaction and design

Questions

Below is a list of questions to be addressed as a result of this requirements document:

Not Doing