|<< Prev||- Up -||Next >>|
The command line interface of ozpm can create packages, install or uninstall them and display miscelaneous informations. Note that packages can't be created by the graphical interface of ozpm. This interface is particularly suited for creating batch files for complex operations.
The avalaible command lines are :
ozpm --help : displays a reminder of command lines.
ozpm --install --in file
--force : installs the package contained in file. file must be a valid .pkg package file previously created by ozpm. ozpm will check if the installation of this package conflicts with another installed package or a previous installation of this particular package. If there is a conflict and the
--force parameter is not specified, a report of the conflict is displayed and the package is not installed. If there is a conflict and the
--force parameter is specified, the conflict is ignored and the package is installed. Warning : use this with caution as forcing installations can mess packages.
ozpm --remove --in pkg : uninstall packages which id is pkg.
ozpm --list : lists all installed packages.
ozpm --info --in pkg : displays informations for the package referenced by pkg which can be :
the name of a package file on the disk (./bloblo.Pkg).
the id of an installed package (mogul:/blabla/bloblo).
ozpm --check : reports package system's integrity (not yet implemented).
ozpm --create --in pkgdescfile
--out pkgfilename : creates a new package. See below for more informations.
An ozpm package file is a compressed file containing :
Informations about the package very like mogul informations.
A directory structure containing all package files.
The creation of a package involves specifying a text file containing the informations about the package (
--in parameter), a subdirectory containing all files of the package (
--prefix parameter) and the package file name (
The package description text file must be formatted as follow :
The file is separated in two main parts : the parameter definition part and the body part. The definition part begins at the start of the file and continues up to an empty line. The body part starts at the line after the empty line up to the end of the file.
The definition part of the text file contains one parameter defined by line. A line is composed of the parameter's name, followed by the character :, followed by the parameter's value. Note that some parameters can be defined several time on different lines.
The body part of the text file is a textual definition of the package. This definition can be either pure ascii text or html text.
The package description text file can contain any parameter definition you might see fit, however there is a set of parameters are strictly required.
The set of parameters that are used by ozpm are :
id : specifies the identifier of the package. If you have a Mogul id for this package, it is a good idea to specify that id. This parameter is required and can be specified only once.
author : specifies the mogul id or alternatively the name of the author of the package. Not required.
version : specifies the version number of the package. Not required.
blurb : specifies a one line description of the package. Not required.
provides : specifies the .ozf Oz module provided by the package. When a user tries to install a package requiring .ozf Oz modules, ozpm proposes to install the packages that provides these modules. Not strictly required, but strongly recommended if relevant. Can be specified several times if needed, one module per line.
requires : specifies the .ozf Oz module required by the package. Ozpm can use this information to help user install the packages providing the required modules when installing this package. Not strictly required, but strongly recommended if relevant. Can be specified several times if needed, one module per line.
The best way to provide modules in Oz is to make them avalaible through URLs. This way anybody in the world connected to the internet can use it. Oz users can place these modules in their local Oz cache preventing the necessary download. The most efficient way of providing binary modules is to provide them ready to install in the user's local Oz cache. Using Mogul and ozpm, this is an easy task :
As you might have noticed, the package definition is similar enough to the mogul entry definition to use the same definition. Specify this file as the
If you use ozskel, you can
make zip to create a directory containing the .ozf oz modules provided by the package. This command creates an ozskel_tmpdir directory and a subdirectory named according to the id of the package. This directory contains the subdirectory structure and files that are to be included in the local Oz cache. Specify this directory as the
It is strongly recommended to use both these tools while creating binary packages.
If you have a mogul entry for your package and create an ozpm binary package for it, make it available in the mogul entry (use the url-pkg parameter). In such a case, the graphical user interface of ozpm will be able to directly install the binary package. Note that the ozpm binary package must have the .pkg extension.
A user Toto that has the mogul id mogul:/toto created a package named dog and want to make it available to other users. He has access to a web site named www.toto.com where he decided to drop the mogul and package files along with the module file.
Toto has defined the mogul entry for the dog package like that :
blurb :A simple dog
This very nice dog can easily attack intruders and protect your home.
This entry was saved to the file named dogentry. Using oskel, Toto runs make zip to create a ozskel_tempdir containing a dictory named toto-dog. Toto can now create the dog.pkg file by the command :
ozpm --create --in dogentry --prefix ozskel_tempdir/toto-dog/ --out dog.pkg
Placing dogentry and dog.pkg onto his web server, Toto has successfully made his binary package available for all other users.
|<< Prev||- Up -||Next >>|