Brooktrout SDK Linux Update/Install

Goals

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

Proposed changes for Linux packages and installation script:

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 applies to both the full package and the non-sr140 package.

After installation, the config directory contains btcall.cfg, callctrl.cfg, BT_CPARM.CFG, and other files. Identical copies of these three 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.) For consistency, this will/should also be done for Windows and Solaris.

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

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 prompt for where to install the package will be skipped and the prior location will be used. For a newly installed package, it will prompt for the location as before (unless prompts skipped).

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.

If the versions of the three config files are not present in the config/samples.cfg directory, that means the original version is older than 6.3, and we cannot apply the means just described. In that case, the three config files will be saved and restored to the config directory. They will be compared to the files from samples.cfg, and if there is a difference, a warning will be displayed.

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.

If the version of the SDK currently installed is earlier than 6.7.3, then the install.sh script will do what the setup.sh does: stop Bostsrv, uninstall the driver, and remove the driver.

Requirements

User interaction and design

Questions

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

Not Doing