Package description files are used to store metadata about a package. This includes information on how to retrieve/build the package and what files are used by the package. Package description go through various phases until they are ready to be used:
Package description files are simple lines of text with fields separated by blanks. The last parameter might be a string containing blanks. No quoting is necessary.
Some records can contain references to variables implemented by String Expansion which might refer to the attribute definition in /etc/upm.conf and the package description.. String expansion is done when content is contained in { }. The following expansions are supported:
Z records will be generated when another package has replaced files of the package. They are a memory of file that have been there and a record of who the villian was.
This contains the text displayed when an overview of packages is requested.
Is used to set up special behavior of the packaging system. Supported are
Retrieve and unpack source code from the indicated location. Contents retrieved are checked against the (optional) md5sum. All the classic tar compressed formats are supported.
Patch-Hinting allows hinting to UPM how the patch has to be applied. Without a hint UPM will try to do patch-magic by trying various way of applying the patch until it fits. Patch hinting is done by appending @ to the end of the patch. If a number follows then that is the -p parmeter value usually given to patch. If some text follows then that is the directory to CD to before doing a patch -p0.
C lines specifiy where binaries with default configuration are available. The arch specifies the basic architecture. Binaries are not as flexible as recipes. The binary will not install if there is a basic incompatibility of attribute settings.
How does a package relate to other packages. Relationships allowed are DEPEND, CONFLICT, RDEPEND, REPLACES, PROVIDE. In the case of PROVIDE the condition is the version of the virtual package and not a condition. REPLACE means that the package referred to is completely removed on installation of this package. A BUILD reference causes version information from the depended on package to be imported into the B records.
Shell commands are run at specific events. All shell commands undergo string expansion first. It is possible to have these shell commands customized by the attributes of the package or of the system. It is strongly suggested NOT to use these event scripts but rather to rely on the attributes controlling the build engine, triggers, Blacklists and system wide scriptsi as much as possible. Package descriptions containing *MERGE events might be considered unsafe at some point. Do not write maintainer scripts that are package specific If you need some functionality then please generalize it and put it into some kind of utility package. The event handlers can then invoke those scripts. Maintainer scripts tend to rot since no one bothers with them. Tools that can be useful for multiple packages will usually be maitained well.
Possible events are:
Attributes allow to specify various information that might be used by dependency conditions and to control and track the build process. Two important attributes are VERSION which is the version of the package installed. VERSION is generated from the version provided at install time. DELTA is used to track revisions to the package description if necessary. It is optional and should only be set if there is a need to track multiple package descriptions for a single VERSION.
Build records are generated during the building of binaries from source. They track the values attributes had when the binary was build. Build records are also used to track the versions of all packages mentioned in build depends. This enables a forced rebuild of all packages that have been generated with a broken version. If dependency checks are being done and references to attributes of packages are made then the build attributes are the significant values..
Installation attributes track what happened during the merging of the package into the real tree. Currently that info includes only version of packages replaced.
Environment variables allow the control of paths such as MANPATH, PATH and the paths used for ld.so as well as default settings in /etc/profile. The V records are processed in order of priority. The packages with the most depth of dependencies are processed first and the packages depending on them later. Therefore packages depending on others can override settings as needed.
Types of variables:
Priority Links are used to manage multiple programs providing the same functionality. For example there are multiple ways to provide a vi editor. Packages can define a priority and the system will point the link to the lowest priority link. The user can display priorities and fix these pointers to a favorite implementation.
Blacklisting is used to prevent packages from installing files. Typically there are files that are dirctories of information such as /usr/info/dir. Many packages provide these files. uPM enforces that no packages should overwrite other packages files and therefore those installs will fail. Blacklisting the file will make it possible for uPM to handle the situation intelligently. ABORT means that packages providing that packages providing that file will not install. WARN means allow the installation but warn about the situation. IGNORE means to simply silently ignore the garbage.
Blacklisting can also be used for Directories. Some major directories can be taken offline. The base package does that extensively to prohibit accidents.
Execute the script when a package writes new contents to the directory or removes files from the directory. {N} contains a list of new files. {R} contains the list of removed files.
A simple example for the use of a trigger is the invocation of ldconfig:
T lib ldconfig T usr/lib ldconfigwill insure that ldconfig is run whenever there is a new file in those directories.