opsystem is comprised of a number of scripts that can be invoked. Each script's role and features are explained below.

:: explodepkg ::

Summary: Explodes the content of either a binary or a source package's archive, protocol version 1.0 in the current directory.
Options: 2 options are available:

Process: If the user does not pass any of the aforementioned options, the script will look through all the agruments, and if they are existing, non-zero, readable, protocol 1.0 binary or source packages, each package's contents will be extracted in the current folder. Obviously, this script is meant to be used only for debugging or testing purposes, and not for the installation of packages on a system, as doing so will not check the package's integrity and resolve dependencies, nor will it upgrade the master database for future removal.

:: mkbinopp ::

Summary: Create a binary .opp package from a binary package archive and package components.
Options: 8 options are available:

Process: The invocation of options is not mandatory as opsystem will first look for an opsystem binary configuration file in the invocation folder (binbuild.conf) and will use those default names when building this package (see sample binbuild.conf below).
However, by passing any of the above options, the global configuration file will be ignored and the script will use those options that were passed as arguements to itself in order to get the required files for creating a binary package file. There are two files whose presence must be mandatory: the package information file, which contains all the necessary information about the package file (such as name, version, architecture, dependecies, description etc. of the binary package) and the file archive (a .tar.bz2 archive), which is, in essence, what will be added to a system once the soon-to-be package will be installed. Optionally, any or all of the following scripts can be added to the binary package file: a pre-install, a post-install, a pre-remove, and a post-remove script. Once all the necessary parts exist, are readable, and their size is greater that 0, the process of putting all the parts together commences. First, the package information file, along with any or all of the pre-install, post-install, pre-remove, and post-remove scripts are added to a "header archive" (header.tbz2) in the build folder. Then, the writing in the future package file really begins. First, a one-line long "marker" is added to the beginning of the package, where the script writes what protocol should be used in order to interpret the package is added. Second, the byte count of the "header archive", it's md5sum, the byte count of the "binary archive", and it's md5sum are all added on the "marker". Third, the "header archive" is dumped in the package file, along with the contents of the "binary archive". Thus, a binary .opp package is successfully created.

:: removepkg ::

Summary: Removes an installed package.
Options: 4 options are available:

Process: When no arguements are passed, except the package name, version, and release, the defaults action is to check if any dependency will be broken if the specified package is removed. If any such dependencies are found, package removal will be aborted. However, you can use the "--force" arguement to force the removal of a package, even if dependencies will be broken as a result.

:: installopp ::

Summary: Installs a binary .opp package file.
Options: 23 options are available:

Process: The defaults action (no options passed except package file name) of this script is to check the package file's integrity, check for (if any) dependencies and if there are any unmet dependencies, their names will be outputed and the script will terminate. If everything is well, it will run the preinstall script (if available), install the binary archive in the root directory, run the postinstall script (if available, and then upgrade the package database.

:: mksopp ::

Summary: Create a .sopp package from a source archive and other components.
Options: 10 options are available:

Process: The invocation of options is not mandatory as opsystem will first look in the opsystem source configuration file (srcbuild.conf) and use those default names when building the package (see sample srcbuild.conf below).
However, by passing any of the above options, the configuration file will be ignored and the script will use those options that were passed as arguements to itself in order to get the required files for creating a source package file. There are three files whose presence must be mandatory: the source archive (a .tar.bz2 archive), which is, in essence, what will be compiled to get a binary package, the "build resource file", which tells opsystem how to compile the source archive in order to get binary files out of it, and the package information file, which contains all the necessary information about the future binary package file (such as name, version, architecture, dependecies, description etc. of the future binary package). We strongly recomment having a build dependency list, which contains a list of the packages that may need to be invoked in the building of the source archive (i.e. autoconf, make, gcc etc.). Optionally, any or all of the following scripts can be added to the binary package file: a pre-install, a post-install, a pre-remove, and a post-remove script. Once all the necessary parts exist, are readable, and their size is greater that 0, the process of putting all the parts together commences. First, the build dependency list file, the build resource file, the package information file, along with any or all of the pre-install, post-install, pre-remove, and post-remove scripts are added to a "header archive" (header.tbz2) in the build folder. Then, the writing in the future package file really begins. First, a one-line long "marker" is added to the beginning of the package, where the script writes what protocol should be used in order to interpret the package is added. Second, the byte count of the "header archive", it's md5sum, the byte count of the "source archive", and it's md5sum are all added on the "marker". Third, the "header archive" is dumped in the package file, along with the contents of the "source archive". Thus, a .sopp package is successfully created.

:: sopp2opp ::

Summary: Converts a source package file (.sopp) into a binary (.opp) one.
Options: 2 options are available:

Process: The defaults action of this script is to check the package file's integrity and make sure that it is indeed a source package with a protocol version that it can indeed understand, and checks build-time dependencies (if any). If any errors or unsatisfied dependencies are met, the script will terminate. Then, a special folder for that package only, containing the sources, resource information for the future binary package, and a "fake" install root, is created in /usr/src/opsystem. Once the build commences, build time output will be displayed on the screen and will also be saved in the invocation folder for future reference. If the source compilation and the "fake" root install succeed, sopp2opp will then invoke the mkbinopp script, as all the necessary parts for a binary package file are present, and a new .opp package file will have been created.