documentation :: opsystem 0.1

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:

	   Usage: explodepkg [PACKAGE_FILE]
	   Explodes the contents of either a binary (.opp) or a
	   source (.sopp) package, protocol version 1.0 in the
	   current directory.
	   
	     --help                   show this page
	     --version                show explodepkg's version
	     
	   Please report bugs on our forum at: http://www.opsystem.org/forum.

2. "--version" displays:

	   explodepkg 0.1
	   Written by Andrei Oprisan.
	   
	   Copyright (C) 2004 the opsystem project (http://www.opsystem.org).
	   This is free software; see the source for copying conditions.  There is NO
	   warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

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:

If this options is passed, immediately following this must be the path and/or name of the binary archive to be used. The presence of a valid archive is mandatory for the script to continue.

	   Usage: mkbinopp [OPTIONS]
	   Create a binary .opp package from a binary package archive and package
	   components.
	   
	   --bin=                   path and/or name of the binary archive
	   [ARCHIVE]                (mandatory)
	   --help                   display this screen
	   --pif=                   path and/or name of the package identification
	   [PIF]                    file (mandatory)
	   --pre-install=           path and/or name of the pre-install script
	   [SCRIPT]                 (optional)
	   --post-install=          path to the post-install script (optional)
	   [SCRIPT]
	   --pre-remove=            path to the pre-remove script (optional)
	   [SCRIPT]
	   --post-remove=           path to the post-remove script (optional)
	   [SCRIPT]
	   --version                show mkbinopp's version
	   
	   Please report bugs on our forum at: http://www.opsystem.org/forum.

If this options is passed, immediately following this must be the path and/or name of the package identification file to be used. The presence of a valid package identification file is mandatory for the script to continue.

If this options is passed, immediately following this must be the path and/or name of the pre-install script that will be executed before the package file's installation. Passing this option is not mandatory, but if specified, the pre-install script must be readable and must have a lenght greated than 0 in order for it to be part of the binary package file.

If this options is passed, immediately following this must be the path and/or name of the post-install script that will be executed after the package file's installation. Passing this option is not mandatory, but if specified, the post-install script must be readable and must have a lenght greated than 0 in order for it to be part of the binary package file.

If this options is passed, immediately following this must be the path and/or name of the pre-remove script that will be executed before the package file's removal. Passing this option is not mandatory, but if specified, the pre-remove script must be readable and must have a lenght greated than 0 in order for it to be part of the binary package file.

If this options is passed, immediately following this must be the path and/or name of the post-remove script that will be executed after the package file's removal. Passing this option is not mandatory, but if specified, the post-remove script must be readable and must have a lenght greated than 0 in order for it to be part of the binary package file.

	   mkbinopp 0.1
           Written by Andrei Oprisan.

           Copyright (C) 2004 the opsystem project (http://www.opsystem.org).
           This is free software; see the source for copying conditions.  There is NO
           warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

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).

# Begin binbuild.conf

# Make sure that the variables "bin" and "pif" are
# pointed to readable files, since the package build
# script will fail if they are not readable.
# You may, optionally, point the variable "preinstall",
# "postinstall", "preremove", and "postremove" to
# corresponding readable scripts.

bin="name-version-release-architecture.bin.tar.bz2"
pif="pif"
preinstall="preinstall.sh"
postinstall="postinstall.sh"
preremove="preremove.sh"
postremove="postremove.sh"

# End binbuild.conf

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:

This options will force the removal of a package even if dependencies will be broken as a result of this action.

	   Usage: ./removepkg [OPTIONS] NAME
	   Removes an installed package.
	   
	     --force                  force removal even if other packages
	                              depend on it
	     --help                   show this message
	     --name=                  show all packages matching passed NAME
	     [PACKAGE_NAME]
	     --version                show ./removepkg's version

	   Please report bugs on our forum at: http://opsystem.org/forum.

NOTE

	   
	   removepkg 0.1
	   Written by Andrei Oprisan.

	   Copyright (C) 2004 the opsystem project (http://www.opsystem.org).
	   This is free software; see the source for copying conditions.  There is NO
	   warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

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:

	   Usage: installopp [OPTIONS] FILE

	   Installs a binary .opp package file.

	     --help                   show this page
	     --force                  ignore any dependency error(s) and proceed
	                              with install
	     --nopreinstall           do not run pre-install script
	     --nopostinstall          do not run post-install script
	     --noinstallscripts       do not run any pre/post install script(s)
	     --noremovescripts        do not copy any pre/post remove script(s)
	                              with package installation
	     --noscripts              ignore any available pre and post install
	                              and remove scripts
	     --root=                  install package in a different place than
	     [PATH_TO_ROOT]           in /
	     --showarch               show package file's architecture build
	     --showdeps               show package file's dependency information
	     --showdesc               show package file's description
	     --showname               show package file's name
	     --showpif                show package file's package information file
	     --showpreinstall         display the pre-install script that comes
	                              with this package
	     --showpostinstall        display the post-install script that comes
	                              with this package
	     --showpreremove          display the pre-remove script that comes
	                              with this package
	     --showpostremove         display the post-install script that comes
	                              with this package
	     --showpackager           show who prepared this package, along with
	                              contact information
	     --showprotocol           show which protocol version was used in
	                              creating the package
	     --showrelease            show package file's release
	     --showsummary            show package file's summary
	     --showversion            show package file's version
	     --version                show /sbin/installopp's version

	   Please report bugs on our forum at: http://opsystem.org/forum.

Using this option before a package file will ignore any dependency error(s) and proceed with installation.

At installation time, right before the package archive is installed in the root directory, if a preinstall script is available, it will be executed. Using this option, however, you can choose not to run this script.

At installation time, right after the package archive is installed in the root direcroty, if a postinstall script is available, it will be executed. Using this option, however, you can choose not to run this script.

At installation time, right before and after the package archive is installed in the root directory, if the preinstall and postinstall scripts exist, they will be executed. Using this option, however, you can choose not to run those scripts.

Once the package file is successfully installed, in it's entry in the master package database can be added preremove and postremove scripts that may be executed before and after the package will be removed. Using this option, you can choose not to add those scripts to the database entry.

By invoking this options, the installation script will ignore all installation and removal scripts which may have come with the package file.

The default action of this script is to install the package file in the root directory (/). However, you can choose to install the package in a different root. Also, the package database entry will be added relatively to the new root, and not in the default root ("/").

Displays the package file's architecture build (from package information file).

Displays the package file's dependency information (from package information file).

Displays the package file's description (from package information file).

Displays the package file's name (from package information file).

Displays the package file's package information file.

Displays the pre-install script that comes with this package.

Displays the post-install script that comes with this package.

Displays the pre-remove script that comes with this package.

Displays the post-install script that comes with this package.

Displays the name of the person that prepared this package, along with contact information.

Displays the name if the protocol that was used in creating the package.

Displays the package file's release number.

Displays the package file's summary.

Displays the package file's version.

	  installopp 0.1
	  Written by Andrei Oprisan.

	  Copyright (C) 2004 the opsystem project (http://www.opsystem.org).
	  This is free software; see the source for copying conditions.  There is NO
	  warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

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:

If this options is passed, immediately following it must be the path and/or name of the source archive to be used. The presence of a valid archive is mandatory for the script to continue.

If this options is passed, immediately following it must be the path and/or name of the build dependencies list. Although the presence of such a list is not mandatory, we strongly recommend that you do have one.

If this option is passed, immediately following it must be the path and/or name of the build resource file. The presence of a valid build resource file is mandatoryfor the script to continue.

	   Usage: mksopp [OPTIONS]
	   Create a .sopp package from a source archive and other components.

	     --src=                   path to the source archive (mandatory)
	     [PATH_TO_ARCHIVE]
	     --builddep=              path to the source package's build time
	     [PATH_TO_BUILDDEP]       dependency requirements (recommended)
	     --buildrc=               path to the source package's build
	     [PATH_TO_BUILDRC]        resource file (mandatory)
	     --help                   display this screen
	     --pif=                   path to the package identification file
	     [PATH_TO_PIF]            (mandatory)
	     --pre-install=           path to the pre-install script (optional)
	     [PATH_TO_SCRIPT]
	     --post-install=          path to the post-install script (optional)
	     [PATH_TO_SCRIPT]
	     --pre-remove=            path to the pre-remove script (optional)
	     [PATH_TO_SCRIPT]
	     --post-remove=           path to the post-remove script (optional)
	     [PATH_TO_SCRIPT]
	     --version                show mksopp's version

	   Please report bugs on our forum at: http://www.opsystem.org/forum.

If this options is passed, immediately following this must be the path and/or name of the pre-install script that will be added for the future binary package that will result from this source one. Passing this option is not mandatory, but if specified, the pre-install script must be readable and must have a lenght greated than 0 in order for it to be added.

If this options is passed, immediately following this must be the path and/or name of the post-install script that will be added for the future binary package that will result from this source one. Passing this option is not mandatory, but if specified, the post-install script must be readable and must have a lenght greated than 0 in order for it to be added.

If this options is passed, immediately following this must be the path and/or name of the pre-remove script that will be added for the future binary package that will result from this source one. Passing this option is not mandatory, but if specified, the pre-remove script must be readable and must have a lenght greated than 0 in order for it to be added.

If this options is passed, immediately following this must be the path and/or name of the post-remove script that will be added for the future binary package that will result from this source one. Passing this option is not mandatory, but if specified, the post-remove script must be readable and must have a lenght greated than 0 in order for it to be added.

	   mksopp 0.1
           Written by Andrei Oprisan.

           Copyright (C) 2004 the opsystem project (http://www.opsystem.org).
           This is free software; see the source for copying conditions.  There is NO
           warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

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).

# Begin srcbuild.conf

# Make sure that the variables "buildrc", "src" and 
# "pif" are pointed to readable files, since the
# package build script will fail if they are not readable.
# We also stringly recommend that you have a "builddep"
# file, listing build-time dependencies; however, we
# do not require it by default. You may, optionally, 
# point the variable "preinstall", "postinstall",
# "preremove", and "postremove" to corresponding 
# readable scripts.

builddep="builddep"
buildrc="buildrc"
src="name-version-release.tar.bz2"
pif="pif"
preinstall="preinstall.sh"
postinstall="postinstall.sh"
preremove="preremove.sh"
postremove="postremove.sh"

# End srcbuild.conf

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:

	   
           Usage: sopp2opp FILE
           Converts a source package file (.sopp) into a binary (.opp) one.

             --help                   display this screen
             --version                show sopp2opp's version

           Please report bugs on our forum at: http://opsystem.org/forum.

 
	   ./sopp2opp 0.1
	   Written by Andrei Oprisan.

	   Copyright (C) 2004 by the opsystem project (http://www.opsystem.org).
	   This is free software; see the source for copying conditions.  There is NO
	   warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

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.