This document is not finished!!!!

NxPackage Design

Methodology

The primary design goal of nxpackage is simplicity. Simplicity in three areas: package management, build management, and installation. The general desire is to move away from systems like RPM or DEB, and toward more intelligent packages. These packages will be able to interact on a level unseen in both RPM and DEB.

Release Plans

Changes of Release Plans
5/28/03	0.2.0 is released, modify roadmap for new changes in design. Ie: No package packet type, more emphasis on information packet types.
7/09/2003	0.30 is released, modify plans for 0.4.0 release, need to fix a few packet types and add some features.
8/13/2003	0.3.1 is released, modify plans to show 0.3.1 release

Version	Date	Description, Plans	Release?
0.1.0	May 20, 20003	Package data system in place, ability to add and remove packet types, ability to create a package, and extract it's context.	RELEASED
0.1.1	May 20, 2003	Bugfix of 0.1.0, Fixed copyright issues - moved to GNU md5 code, fully GPL licensed	RELEASED
0.2.0	May 28, 2003	Information packets should be fully functional. Start of actuall "package" packet type May 28, 2003: Info packet driver working, although not well tested. Package packet type now is a subset of the information packet type. (An int array of information packets.)	RELEASED
0.3.0	July 9, 2003	Package packet type should be somewhat functional, API for package creation stabilises. May 28, 2003: Information packet transfer of data from C to python. Start of "install" action(test purposes only). Package information array list should be read into a python dictionary and, at least displayed by install action.	RELEASED
0.3.1	August 13, 2003	Bug fix release. Fixes several small issues with package management. Install action seperated out into it's own source tree.	RELEASED
0.4.0		Addition of package and file database, python install/remove scripts should now be executed. May 28, 2003: Start of package descriptions database/patch set begins. July 9, 2003 Fix directory packet to include permissions and other infos. Nxpak should be able to parse the package dependency string. Package build scripts should be able to add python scripts for install, remove, or whatever.
0.5.0		Fix as many possible bugs in verison 0.4.0. Clean up the database structure. May 28, 2003: Add basic dependency checking during package install. Should be a maintence release for the entire system development.
0.6.0		Start of package delivery system. Ability to download binary packages, or source packages. May 28, 2003: Creation of a package directory files/database(similar to Packages in Debian), should be automated with a single command.
0.7.0		Addition of signing code to package delivery system
0.8.0		Bug fixes to delivery system. Package manager should be near fully functional.
0.9.0		Big Indian / Little Indian fixes. Add system types.
1.0.0		Bug fixes for 0.9.0, package manager should be fully functional

Packet Types

Information Packet

An information packet contains a single item of information. This information is usually used for metadata, or, for by the package dictionary. The information packet is made up of three parts. First, a string that should identify the information. Second, a string that identifies a group that this information belongs to. Third, a type of information and then the information itself.

Current information types are:
1. String: A standard, null terminated, string of information.
2. Public Key: An identifier of a public key crypto.
3. PNG: A png image file
4. Int: an integer
5. String List: A set of strings

File Packet

The file packet stores a single file, as well as permissions, ownership information, and link destination if applicable. Also included is an md5sum of the file for verification.

Package Scripts

When installing, removing, or upgrading a package, it is often neccessary to have scripts that update files, check for dependencies, compile modules, or perform general maintnence. NxPackage uses Python as the language which install and remove scripts are written in. These scripts have full access to the various methods in the installer. Each package may contain a single Python script. Inside this Python script should be Python functions corresponding to the desired execution time. The table bellow shows a list of supported functions, when they are execute, and the actions that they should take. If these functions are not existant in the script, or the script itself doesn't exist, the default methods are used. To insure that a script doesn't trample on currently existant globals, it is recommended that all private functions and data values be prepended with "nspkg_". It is highly recommended that one allow the package to use the default scripts. Default scripts are available to the internal package scripts. They are named the same as the function names that should appear in the package script, but are prepended with "def". (Eg: the default install script may be accessed as "definstall")

Function Name	Description	Execution Time
preinstall(dict)	A preinstallation script. This script should check any extra required dependencies, and insure that the package is compatible with the system. If there is a problem preventing the package from being installed it should return a string with a detailed explanation of the problem. Otherwise, it should return None. This function should NOT, under ANY circumstances write to the disk(excepting tmpfiles in /tmp), or perform installation procedures. This script is passed the package dictionary.	immediately before package installation
install(dict)	An installation script. As arguments, this script is passed the package dictionary. It is responsible for unpackaging, and writing the package files to disk. In addition, it may create files dynamically, compile needed modules, or perform any other tasks that a software program requires. If there is an error, then the script should return a detailed error message, and the package manager will automatically remove any files reported as installed by the package.	after preinstall
postinstall(dict)	This script is executed after the installation of all packages in a single transaction are installed. This package may also check for errors, and perform operations. If an error is found, it will be displayed to the user, however, the package will not be removed. All serious error checking should occur in the install portion. The idea of postinstall is to do required system maintnence tasks.	after all packages are installed.
preupgrade(dict)	This script is equivelent to the preinstall script, only it is used during package upgrades.	immediately before package upgrade

Dependency Information

Formatting Object Strings

Each dependency string is built from a collection of individual objects. The object is built from a type specifier, object, version, and/or suggested package specifier seperated by semi-colons(;). The table bellow breaks out each individual field:

Format	Object and Version	Suggested and Version	Example
P (PACKAGE)	Package, version recommended but not required	Not Applicable	(P;bash>=2)
R (RECOMMEND)	Package, version recommended but not required	Not applicable	(R;XFree86>=4.0)

When a object and version or suggested package is given, it need to contain version information. The version information is seperated from the package name by a colon(:). The package name appears before the colon, while the version information appears after the colon. The version number should start with a range specifier('=', '>', '<', '=<', '<=', '=>', '>=' for equal, lesser, greator, lesser or equal to, lesser or equal to, greater than or equal to, greater than or equal to) followed by a version number. If no range specifier appears, and equal('=') is assumed. The version number should be formated as A.B.C.D where A is the major, b is the minor, C is the subminor, and D is the build number. If the version number is left completely off, all fields are set as do not care. Any missing portion of the version number will be deemed as a "don't care".

The entire package or object and version string should be placed in parenthesis('(', ')'). For added flexibility, anystatement can be negated by placing an exclamation mark immediately after the opening parenthesis. Bellow are examples of strings:

1. (P;bash:>=2.2.3) - Require bash greater than 2.2.3(2.2.4, 3.0, and 2.3.0 would all work)
2. (P;bash:) - Require ANY version of bash.
3. (!P;bash:) - Require bash NOT be installed
4. (!P;XFree86:<=4.0) - Require XFree86 greater than 4.0

Note that there is no way of specifying package version ranges in the version number specification. However, these can be specified by using the the dependency string.

When things go wrong

When a dependency isn't met, the package manager displays a list of all required packages that need to be installed, or the packages that must be removed. In the event that multiple possible situations will solve the dependency, the first solution in the dependency string is printed out.

Package Security

Package Signing

Both RPM and DPKG have support for package signing inside the package files. However, nxpkg does not support package signing inside the package itself. Instead, this has been seperated to the package delivery system. When a package is downloaded by nxpackage, the downloader also checks for a package signature file. If existant, this signature file is downloaded along with the package. This method solves several issues:

1. Package signing is not required to create or use a package, instead is just provides an extra layer of security to those who desire it.
2. Package signing may be used, and verified, using standard available tools, in this case, gnupg.
3. The complexity of the package file is kept at a minumum.

Binary Checksums

A further level of security is found in the built in support for md5 checksum checking. Every file included in a package has an md5 checksum. Every file installed on the system is checked against this checksum for verification(unless no verification is specifically requested). These md5 check sums are further stored inside a database, allowing the user to check if something has modified files. (Say a user modification or a trojan.)

Document Changes

Date	Document Change
July 15, 2003	Removed file based dependencies. I'm forced to agree with the Debian people. They stink. The downsides in all areas remove any advantage that we might have seen with them. Also, modified description of the dependency string to fit the current code.