head 1.80; access; symbols; locks; strict; comment @# @; 1.80 date 2004.01.14.11.02.04; author ms; state Exp; branches; next 1.79; 1.79 date 2003.08.26.08.30.45; author cs; state Exp; branches; next 1.78; 1.78 date 2003.07.28.12.32.51; author ms; state Exp; branches; next 1.77; 1.77 date 2003.07.28.10.57.02; author ms; state Exp; branches; next 1.76; 1.76 date 2003.05.09.15.48.40; author ms; state Exp; branches; next 1.75; 1.75 date 2003.05.09.13.57.25; author ms; state Exp; branches; next 1.74; 1.74 date 2003.05.09.13.50.03; author ms; state Exp; branches; next 1.73; 1.73 date 2003.04.29.14.47.57; author ms; state Exp; branches; next 1.72; 1.72 date 2003.04.22.14.23.16; author ms; state Exp; branches; next 1.71; 1.71 date 2003.04.22.14.09.42; author ms; state Exp; branches; next 1.70; 1.70 date 2003.04.22.13.51.40; author ms; state Exp; branches; next 1.69; 1.69 date 2003.04.02.13.02.15; author thl; state Exp; branches; next 1.68; 1.68 date 2003.04.02.10.04.29; author thl; state Exp; branches; next 1.67; 1.67 date 2003.01.28.08.59.55; author ms; state Exp; branches; next 1.66; 1.66 date 2003.01.28.08.29.21; author cs; state Exp; branches; next 1.65; 1.65 date 2003.01.21.11.13.55; author ms; state Exp; branches; next 1.64; 1.64 date 2003.01.15.11.09.44; author ms; state Exp; branches; next 1.63; 1.63 date 2003.01.14.10.36.09; author ms; state Exp; branches; next 1.62; 1.62 date 2003.01.14.10.11.40; author ms; state Exp; branches; next 1.61; 1.61 date 2002.12.19.10.52.46; author rse; state Exp; branches; next 1.60; 1.60 date 2002.12.11.10.41.30; author ms; state Exp; branches; next 1.59; 1.59 date 2002.12.11.10.40.58; author ms; state Exp; branches; next 1.58; 1.58 date 2002.12.04.09.25.58; author ms; state Exp; branches; next 1.57; 1.57 date 2002.12.04.09.10.24; author ms; state Exp; branches; next 1.56; 1.56 date 2002.11.07.11.15.33; author ms; state Exp; branches; next 1.55; 1.55 date 2002.08.13.11.46.33; author ms; state Exp; branches; next 1.54; 1.54 date 2002.08.05.15.53.02; author ms; state Exp; branches; next 1.53; 1.53 date 2002.08.02.15.55.13; author openpkg-cvs; state Exp; branches; next 1.52; 1.52 date 2002.08.02.15.49.58; author openpkg-cvs; state Exp; branches; next 1.51; 1.51 date 2002.08.02.15.27.16; author openpkg-cvs; state Exp; branches; next 1.50; 1.50 date 2002.07.29.07.08.14; author openpkg-cvs; state Exp; branches; next 1.49; 1.49 date 2002.07.12.11.54.52; author openpkg-cvs; state Exp; branches; next 1.48; 1.48 date 2002.07.12.10.41.38; author openpkg-cvs; state Exp; branches; next 1.47; 1.47 date 2002.07.12.09.40.40; author openpkg-cvs; state Exp; branches; next 1.46; 1.46 date 2002.07.12.09.31.35; author openpkg-cvs; state Exp; branches; next 1.45; 1.45 date 2002.07.09.15.05.32; author openpkg-cvs; state Exp; branches; next 1.44; 1.44 date 2002.07.09.15.03.43; author openpkg-cvs; state Exp; branches; next 1.43; 1.43 date 2002.03.26.14.10.42; author ms; state Exp; branches; next 1.42; 1.42 date 2002.03.08.15.04.25; author ms; state Exp; branches; next 1.41; 1.41 date 2002.02.26.09.49.32; author ms; state Exp; branches; next 1.40; 1.40 date 2002.02.22.13.52.48; author ms; state Exp; branches; next 1.39; 1.39 date 2002.02.19.14.24.57; author ms; state Exp; branches; next 1.38; 1.38 date 2002.01.21.15.57.35; author ms; state Exp; branches; next 1.37; 1.37 date 2001.12.18.14.28.02; author ms; state Exp; branches; next 1.36; 1.36 date 2001.12.18.14.16.36; author ms; state Exp; branches; next 1.35; 1.35 date 2001.12.18.13.51.12; author ms; state Exp; branches; next 1.34; 1.34 date 2001.12.18.13.36.36; author ms; state Exp; branches; next 1.33; 1.33 date 2001.12.17.17.09.56; author ms; state Exp; branches; next 1.32; 1.32 date 2001.12.14.14.19.47; author ms; state Exp; branches; next 1.31; 1.31 date 2001.12.03.17.01.32; author ms; state Exp; branches; next 1.30; 1.30 date 2001.11.27.17.42.38; author ms; state Exp; branches; next 1.29; 1.29 date 2001.11.23.17.20.04; author ms; state Exp; branches; next 1.28; 1.28 date 2001.11.21.16.29.02; author ms; state Exp; branches; next 1.27; 1.27 date 2001.11.06.16.36.36; author ms; state Exp; branches; next 1.26; 1.26 date 2001.11.02.13.59.10; author rse; state Exp; branches; next 1.25; 1.25 date 2001.10.30.18.16.35; author ms; state Exp; branches; next 1.24; 1.24 date 2001.10.30.11.13.13; author thl; state Exp; branches; next 1.23; 1.23 date 2001.10.29.16.09.05; author thl; state Exp; branches; next 1.22; 1.22 date 2001.10.27.20.03.31; author ms; state Exp; branches; next 1.21; 1.21 date 2001.10.26.17.35.44; author ms; state Exp; branches; next 1.20; 1.20 date 2001.10.25.18.06.02; author ms; state Exp; branches; next 1.19; 1.19 date 2001.10.24.17.40.23; author ms; state Exp; branches; next 1.18; 1.18 date 2001.10.24.09.13.35; author ms; state Exp; branches; next 1.17; 1.17 date 2001.10.23.14.22.14; author ms; state Exp; branches; next 1.16; 1.16 date 2001.10.23.14.00.29; author ms; state Exp; branches; next 1.15; 1.15 date 2001.10.22.09.25.42; author rse; state Exp; branches; next 1.14; 1.14 date 2001.10.19.16.28.00; author ms; state Exp; branches; next 1.13; 1.13 date 2001.10.18.12.32.27; author ms; state Exp; branches; next 1.12; 1.12 date 2001.10.17.18.24.35; author ms; state Exp; branches; next 1.11; 1.11 date 2001.10.16.16.10.56; author ms; state Exp; branches; next 1.10; 1.10 date 2001.10.12.15.42.34; author ms; state Exp; branches; next 1.9; 1.9 date 2001.10.09.13.44.57; author ms; state Exp; branches; next 1.8; 1.8 date 2001.10.08.16.44.39; author ms; state Exp; branches; next 1.7; 1.7 date 2001.09.26.14.23.47; author ms; state Exp; branches; next 1.6; 1.6 date 2001.09.02.11.25.58; author rse; state Exp; branches; next 1.5; 1.5 date 2001.08.30.13.44.29; author rse; state Exp; branches; next 1.4; 1.4 date 2001.08.30.13.35.18; author rse; state Exp; branches; next 1.3; 1.3 date 2001.08.28.10.59.59; author rse; state Exp; branches; next 1.2; 1.2 date 2001.06.29.11.34.30; author rse; state Exp; branches; next 1.1; 1.1 date 2001.06.23.11.38.55; author rse; state Exp; branches; next ; desc @@ 1.80 log @Remember change of directory name for binary packages, and edit random device requirements text @ text @ The OpenPKG Handbook The definitive guide to OpenPKG for users and developers Cable & Wireless, Munich Ralf S. Engelschall Michael Schloh von Bennewitz January 2004 OpenPKG (pronounced open-pee-kay-chee) is a self-contained cross-platform software-packaging system for Unix computers. It is primarily maintained for Sun Solaris (SPARC), FreeBSD (ix86), Red Hat Linux (ix86), Debian GNU/Linux (ix86), and is easily portable to other Unix flavors. OpenPKG uses software-packaging technology based on an extended version of Red Hat's popular Red Hat Package Manager (RPM, v4) and supports both source and binary packages. OpenPKG leverages these open standards to the user's benefit, and there are already over 200 OpenPKG RPM packages publicly available. OpenPKG's unique RPM extensions allow it to use a very clean and short package specification. Furthermore, OpenPKG packages can be built without root privileges or write access to the target installation hierarchy. OpenPKG is classified as Open Source software and is available from http://www.openpkg.org/ and ftp://ftp.openpkg.org/. Although OpenPKG itself is licensed with BSD-style terms, resulting OpenPKG packages are still licensed according to their underlying third party license terms. OpenPKG is a project of the Development Team from the Cable & Wireless Deutschland Application Services division, located in Munich, Germany. The OpenPKG project was founded in November 2000 by Ralf S. Engelschall and is currently deployed for Cable & Wireless customers in Germany. User's Guide The first part of the OpenPKG Handbook contains information helpful to an OpenPKG user, defined as a person intending to install OpenPKG and OpenPKG packages on a target computer. In the OpenPKG Handbook User's Guide, we begin introducing OpenPKG from a user's point of view. A more curious user can additionally reference developer-oriented OpenPKG documentation in of the handbook, and may benefit from reading both parts indeed. Introduction Typical Computing Resources Most companies or other groups pooling their computing resources have similar characteristics we can describe and study. Different hardware types are often administered by a variety of engineers with different skills and preferences. Different operating systems run on the various hardwares, and the diversity of such an environment often leads to a large and decentralized collection of installed software applications. Problems Encountered In such a complex computing environment, problems may be difficult to anticipate and harder to correct. Failures may reduce production or cause unnecessary delays. More concern must be given to the potential data hazards and security risks introduced by the ad hoc solutions mixed together when no installation standard exists. An example of such a situation occurs when complexity mounts and two groups disagree on the file system path of a software installation base. The groups may have different goals, and any flexible installation standard would accommodate such diverging needs. A software installation base may have vendor applications, proprietary applications, or a combination of both. In these cases, the method of administrating the installation base of computing resources makes quite a difference. In the classical approach, vendors use their own application packaging facility. This results in a longer installation time and larger potential of problems during later maintenance such as security updates. More attention must be given to the education of engineers involved in the administration of such a classical and problematic computing environment. Requirements For Success To improve the outcome of such a process, several requirements must be considered. The time of installation and configuration should be reduced to a minimum without introducing unreasonable configuration defaults or restrictions. The maintenance cycle should be reduced and simplified to allow for easy verification and upgrading. An engineer should encounter few problems when backing out changes or reverting to a previous installation. Notably, An installation should retain its configuration during adjustments or subsequent installations, and the effects of an uninstallation should be predictable and correct. Results should be independent of the platform or engineer performing the installation. Rather, each installation should be reproducible anywhere the standard is valid, and should apply to all platforms in use by the group. To increase usability and for reasons of quality assurance, the implementation of these requirements should be available to others as Open Source. Existing Solutions There exist solutions to the aforementioned software installation and management problems in several places. Unfortunately, in all of the existing solutions, some important requirements are not fulfilled. The Debian Project has delivered a software-packaging implementation called dpkg/apt. In the case of dpkg/apt, Debian provides many desirable features by supplying tools that allow the building of an installation architecture. However, its support for multiple vendor files wrapped into one package is poor. The solution is also not as clean as desirable, as each package requires many separate files. This introduces unnecessary risks in copying complex file groups or otherwise organizing packages. Lastly, the interface between apt and dpkg is difficult to use, and does not adequately supply the functionality needed in repeated installations. The FreeBSD Project has released some package utilities such as ports and pkg_xxx, which unfortunately are quite implementation-specific to the BSD architecture. To defeat the inherent portability problems requires such a dramatic strip down that all but the most basic make functionality is rendered useless. Additionally, Ports is mostly intended for source distribution while pkg_xxx deals with binary distributions. The interface between the two distribution models is poor, causing a user to unnecessarily choose one of the two and discard all other (quite useful) functionality. A coalition of Linux distributors once banded together in a half-successful attempt at an industry-standard application packaging facility. Red Hat, SuSE, and MandrakeSoft distribute the Red Hat Package Manager, which incidentally is used in the OpenPKG implementation. However, the RPM solution lacks a larger framework for administrating an installation of applications as one software base. One cannot preview the dependencies between tools and libraries before deciding to install an application, for example. Two hardware companies, Silicon Graphics and Sun Microsystems, also produce operating system software for their hardware products. To install applications they have created proprietary installation standards and bundled tools with their OS distributions. In later distributions of Sun Solaris, a variety of utilities with the name pkgxxx are used to install and manage software. Based on this model, the higher level package management tools like WebStart and JumpStart introduce power to end users and administrators alike. Unfortunately, these solutions are not available on other platforms and are therefore unusable should a single implementation strategy be required. Even worse, the implementations are not Open Source, introducing support problems and denying access to source code should bug fixes or improvements be desired. Silicon Graphics and its IRIX operating system face similar problems. The OpenPKG Solution The makers of OpenPKG have decided to provide more than just another implementation to this mixture of diverging efforts meeting with half-success and half-failure. The goals inherent to the OpenPKG application packaging facility are many, and they are consistently met as the architecture moves into the finer stages of development. Will OpenPKG succeed where others have not? Only time will tell, but engineers all over the world will be involved in making this decision. OpenPKG is Open Source, meaning that its source code is not just available for use, but can be manipulated according to the license bundled with each distribution of OpenPKG. There is good news in that the worldwide Internet Service Provider Cable & Wireless has decided to support the development of OpenPKG, guaranteeing an immediate base of knowledge and usage. This also means that some typical hurdles experienced by many other open-source projects will not affect the progress and development of OpenPKG. OpenPKG solves the typical problems associated with installing and maintaining a base of applications with almost any software and hardware combination, administered by any number of diversely skilled administrators of pooled computing resources. It fulfills these formidable expectations without breaking common rules of security or usage. It will not force an administrator to reconfigure an application after updating to a newer package, for example. To meet the goal of becoming a standard across many platforms, OpenPKG is based on the RPM architecture introduced by Red Hat. RPM is already in use across most Linux distributions. New features have been built into the RPM framework through extensions of its architecture and reimplementation. RPM has not been redesigned, though the implementation of RPM found in OpenPKG is more flexible and robust than the original. The decision to extend RPM was not difficult, especially considering that none of its original benefit or standard functionality were lost. The problem of installing OpenPKG is typical of other package managers or compilers requiring compilation. A bootstrap procedure is used, in which RPM and other essential tools are bundled together and used to 'install the installer'. This bootstrap package is manipulated by a shell script, which runs and creates a self-contained hierarchy of directories and files for use by OpenPKG. The bootstrap script also establishes a sort of context or environment in which OpenPKG runs. Specifically, initial configuration involves the operating system and some of its more common control facilities. The four points of contact at which OpenPKG interacts with the operating system are the file system location corresponding to the given prefix (1), its permissions with owner and group attributes (2), the root cronjob (3), and the init script (4). To learn more about the bootstrap procedure, please see . Software Packaging Package Life Cycle The life cycle of a package involves twelve stages of development or usage. Some stages refer to work only carried out by a developer while other stages are useful only to an administrating user. In a few cases, both a user and developer can complete a packaging stage. A detailed description of packaging stages is useful in understanding the course of development and usage of a typical OpenPKG package. Each of the stages in question correspond to an entry in , and can be further understood after reference to . Package development and usage sequence Packaging stage Developer User Package Specification mandatory - Vendor Source Transfer mandatory - Vendor Source Adjustment optional - Vendor Source Preparation mandatory optional Vendor Object Build mandatory optional Vendor Object Installation mandatory optional Vendor Object Packaging mandatory optional Package Transfer - mandatory Package Installation - mandatory Package Verification - mandatory Package Upgrade - mandatory Package Uninstallation - mandatory
Package Specification A package developer begins the creation of a package by writing its RPM specification file. Such a spec file controls all aspects of package behaviour. Spec file details and authoring instructions are found in . $ vi foo.spec Vendor Source Transfer Before considering any source operations, the package developer must first transfer the original vendor distribution files to the local packaging environment. RPM specifies that such source files be 'pristine', meaning unmodified from their original state. OpenPKG follows this standard as well, for reasons of consistency and portabilityBailey, Edward C. "Pristine Sources." Maximum RPM. Red Hat Software, Inc. 17 February, 1997. 115-116. . For example, the developer may download the application sources from an ftp server whose URL is specified in the spec file. In other situations the developer might choose to perform the transfer via a HTTP server, TFTP server, or directly copy the files from some network location to the local computer. $ rpm --fetch foo.spec Vendor Source Adjustment Under ideal conditions, the vendor sources need no further modification before moving to the next stage of package development. However, the package developer may optionally adjust the local vendor sources should less ideal conditions prevail. A typical adjustment often involves porting the application to run correctly under all target platforms. The developer may prepare a set of patches that specify how OpenPKG must transform one or more of the source files to compile and run on the target platform. This can be accomplished by redirecting the output of the diff command to a 'patch' file. $ diff -u3 foo.orig foo > patchfile Additionally, security issues may also compel a developer to integrate a patch file into an OpenPKG package. If a new version of the application later solves the problem, the developer can remove the security patch and create a new OpenPKG package update for distribution. Fortunately, these patch files are straightforward to create and administer. They become part of a package simply by adding them to the vendor distribution files. Vendor Source Preparation The package developer must prepare the vendor sources before they may be built. During this preparation, the developer extracts the vendor distribution files to a directory, applies both vendor patches and patches from earlier adjustments, and finally changes the file permissions in the resulting source tree. The developer then applies the rpm command to build the file structure into a format that RPM can further manipulate. $ rpm -bp foo.spec Vendor Object Build Once sources are ready for building to all target platforms, the package developer takes the same approach as a user in later stages. Namely, the package is configured for a particular platform and subsequently built. The vendor sources are typically compiled according a Makefile of some sort, and the resulting file structure is ready for installation. Command line options can be used to manipulate the options a package offers, as explained in . $ rpm -bc --short-circuit foo.spec Vendor Object Installation With the platform-specific binaries constructed by the vendor object build stage, the developer can complete an actual OpenPKG installation. In order to facilitate later bundling of the files in the distributed package, this stage of installation must use its own directory and not $opkg_root as is usually the case. The developer therefore redirects the package to a fake installation hierarchy, and installs the vendor objects. Command line options can be used to manipulate the options a package offers, as explained in . $ rpm -bi --short-circuit foo.spec Vendor Object Packaging To finally create the one-file solution commonly known as an OpenPKG package, the contents of the vendor object installation are rolled (bundled) into a single binary file. A wise developer will first inspect the installation hierarchy to ensure that no temporary or residual files are included in the package. Command line options can be used to manipulate the options a package offers, as explained in . $ rpm -bs foo.spec $ rpm -bb --short-circuit foo.spec Package Transfer Before initiating an OpenPKG package installation, the user must obtain the desired package. In many cases, this simply means that the user copies the package file from a remote network location to the target computer. Any number of methods can be used. Some examples are scp, ftp, ssh and lynx, and plain copy commands to local storage devices. $ scp -r user@@remote:/pkgs/foo.<V>-<R>.<arch>-<os>.<id >.rpm /mycomputer/ Package Installation To finally install a package to the target OpenPKG hierarchy, the user issues the rpm command giving the 'i' installation flag as an option. Additional flags such as 'v' or 'h' for verbosity and hash marking are optional, but do supply useful information. $ rpm -ivh foo.<V>-<R>.<arch>-<os>.<id >.rpm Package Verification To verify that a package has successfully installed and is consistent with its spec file, the user may issue a package verification command as described by . The information reaped from such verification is useful when debugging or correcting the installation of a problematic package. Should there be no problems with a package installation, the verification command will exit silently. Of interest is that after a package is installed, it may be referenced by its simple prefix name as the following example shows. Reinstalling or updating the package requires the full path and file name, however. $ rpm -V foo Package Update Updating a package means that a package with the same prefix name (foo in this case) will be installed, overwriting any non-configuration files from the previous installation. The user typically updates a package in order to use a newer version of the same software application. Logically, the new package version will replace the functionality of the old. Should the user desire to keep the old package installation even as the new one is installed, modifications must be made to the package's spec file in other stages of its lifecycle (see .) Updating a package with an older version is not possible. To accomplish this, the user must first uninstall the current package, and then initiate a new installation of the older version. The following command will update a package to the version specified by the file name. OpenPKG will write over the old installations files. $ rpm -Uvh foo.<V>-<R>.<arch>-<os>.<id >.rpm Package Uninstallation An OpenPKG package finishes its life at the stage of uninstallation. Here, the user removes the package from the OpenPKG hierarchy both logically and physically. The source, binary, and configuration files corresponding to the package in question will be removed from the user's file system. As described in , some of the uninstalled package's files may intentionally be left in the OpenPKG hierarchy for purposes of later configuration. $ rpm -e foo Package Data Flow Package Data Flow As an OpenPKG developer or user works with a package, the package's data and state undergo various changes from one stage to the next. File Hierarchy File Hierarchy Overview A key advantage of OpenPKG involves its ability to run with few or no dependencies to other system utilities and applications. To achieve this measure of cohesion, OpenPKG creates its own file hierarchy during its bootstrap. All the universe known to OpenPKG exists only in this hierarchy, called $opkg_root in OpenPKG's run time environment. The actual name of the hierarchy is established during bootstrap and can be influenced by defining the configuration variable --prefix=$opkg_root. After the OpenPKG bootstrap finishes, the user can expect to see a new hierarchy of files on the file system. The variable $opkg_root will contain a path that matches whichever was given along with the bootstrap shell command. To learn more about the bootstrap procedure, please see . In all subsequent package installations, OpenPKG will control its repository and configuration by manipulation of data within this hierarchy established during the bootstrap. Careless removal or other modification of parts of this hierarchy can cause OpenPKG's internal structure to become inconsistent and may lead to undefined behavior. The rpm command will fail, for example, should the $opkg_root/RPM or SRC directories be changed or removed. Thankfully, there are few if any reasons for such unadvisable direct file system editing under an automated system like OpenPKG. Cool World Incidentally, an OpenPKG instance is often written to a directory called "cw". Though the historical roots of OpenPKG lie in the development labs of Cable & Wireless in Munich, this naming convention is more attributed to the fact that all OpenPKG users live in a very Cool World. Hence, "cw" is OpenPKG engineer Thomas Lotterer's friendly reminder of how cool you really are as an OpenPKG user. Elements of the File Hierarchy Many different pieces assemble to make the OpenPKG file hierarchy. Strictly speaking, these pieces are the individual directories, files, and links of the file system under use. OpenPKG obtains a handle to the path where it should lay out its hierarchy of data, and then proceeds to create directories and write other data such as file permissions. This occurs during the bootstrap of OpenPKG. Except for the subsequent installations this file hierarchy is expected to remain constant. OpenPKG file hierarchy +-Basenames |-Conflictname |-Group +-README |-Name | +-DB/------|-Packages | |-PKG/ |-Providename |-RPM/----|-SRC/ |-Requirename | +-TMP/ +-Triggername | |-bin/----+-rpm | +-rpm2cpio |-sbin/---+-lsync | +-rpmtool | | +-rc |-etc/----|-rc.env +-pubring.gpg | |-rc.d/ |-rpmdev.mk | +-openpkg/-|-rpmmacros | +-rpmrc | | +-find-provides | |-find-requires | |-macros | |-rpm | |-rpmb | |-rpmdb |-lib/----+-openpkg/-|-rpme | |-rpmi | +-man1/ |-rpmk | |-man2/ |-rpmpopt-4.0 | |-man3/ |-rpmq /$opkg_root/-| |-man4/ |-rpmt | |-man5/ |-rpmu |-man/----|-man6/ +-rpmv | |-man7/ | +-man8/----+-lsync.8 | |-rpm.8 |-include/ |-rpm2cpio.8 |-info/ +-rpmtool.8 |-libexec/ |-share/ |-var/ | +-README | |-PKG/ | |-bin/ +-man1/ +-local/--|-sbin/ |-man2/ |-etc/ |-man3/ |-include/ |-man4/ |-info/ |-man5/ |-lib/ |-man6/ +-man/-----|-man7/ +-man8/ Security Through Userids and Groupids Many daemon packages use special users and groups for improving security. OpenPKG uses four distinct Unix user/group id pairs. They are specified during the bootstrap of a new OpenPKG instance. The eight names can either be set individually or a common prefix can be specified. Existing system users can be choosen to allow indirect control of user/group numbers and to integrate OpenPKG into enterprise environments with networked (i.e. NIS, LDAP) account management. It's up to the administrator to decide if one or more OpenPKG user/group functionalities use the same account, whether preexisting system accounts are being used or not and if accounts are reused accross OpenPKG instances and even machines. In case of a non-privileged OpenPKG instance, all users and groups usually map to a single pair. Please note that some software packages (i.e. sendmail, postfix) actually require the user/group ids to be different. They verify this at run-time and will refuse to work if the setup violates their hardcoded security policies. The pay off consolidating multiple OpenPKG user/group functionalities into a single Unix account is the inability to continue use of those applications. In fact, enabling those applications were the driving force behind OpenPKG to support multiple users. Please understand that while additional users and groups help to isolate OpenPKG from the host and one OpenPKG instance from another, the gain in security is still small. To protect files from being accidentally overwritten during development of a package, a developer must use the OpenPKG feature of building a package as non-root. Even this is not perfect and sometimes it's best to dedicate a machine to development. Installing and maintaining daemons, set-uid executables etc. still requires the system administrator to work as "root" or at least begin administration as "root" and substitute user identity with the OpenPKG management user using su(1) or a similar mechanism. Trying to use the additional accounts to exclusively subdelegate administration or to protect the host from OpenPKG instance managers is a waste of time as the managers can easily overwrite files (i.e. cron jobs) which are eventually executed by the superuser. To increase protection of the host and between OpenPKG instances, additional precautions must be taken. Using chroot(1M) on Linux or Solaris aka chroot(8) on FreeBSD is a step in the right direction but it is limited to separating access to files, not sockets or any system calls. Today, the fullest segregation can be achieved through deployment of vserver for Linux or jail(8) for FreeBSD. As described in , the installing administrator must give a user and group name as arguments when bootstrapping a new OpenPKG instance. This user and group name pair indicates the management user and group. If the administrator does not explicitly specify the additional superuser, restricted and non-privileged user and group names, they will be determined by using the given management user and group names as a prefix. By default, the restricted user name will match that of the management user, adding a '-r' extension. The non-privileged user name will match that of the management user, but add a '-n' extension instead. The superuser user name is 'root' by default. The OpenPKG groupids are handled in the same way. The administrator can read the unix password file /etc/passwd and unix group file /etc/group to see the new entries. Arguments given during bootstrap The additional user and group names may be customized to suit the needs of the administrator. Additional arguments may be given when running the bootstrapper (see ) to accommodate special user and group names. Specify the name of the management user with --musr=<name>, the restricted user with --rusr=<name>, the non-privileged user with --nusr=<name>, and the superuser user with --susr=<name>. Accordingly, group names can be specified with --mgrp=<name>, --rgrp=<name>, --ngrp=<name>, and --sgrp=<name>. --musr=<management user name> --rusr=<restricted user name> --nusr=<non-privileged user name> --susr=<superuser user name> --mgrp=<management group name> --rgrp=<restricted group name> --ngrp=<non-privileged group name> --sgrp=<superuser group name> Using the Userid and Groupid Variables These user and group names can be queried from within the OpenPKG specification file. The variables %{l_musr}, %{l_rusr}, %{l_nusr} and %{l_susr} expand to the management, restricted, non-privileged and superuser. The variables %{l_mgrp}, %{l_rgrp}, %{l_ngrp} and %{l_susr} expand to the management, restricted, and non-privileged groups. RPM Maintained $opkg_root/* /$opkg_root/RPM, /$opkg_root/bin, and nearly every other subdirectory of /$opkg_root is maintained by the rpm command as it adds, updates, and removes packages. The administrator must simply issue rpm commands, and not worry about what goes where or what might or might not 'look right'. This is because according to public standards, OpenPKG maintains its hierarchy in a uniform manner. Administrator Maintained $opkg_root/local In an ideal world, there would be an OpenPKG package for every software application. While this might be a reality some day, there still exist applications that the administrator must manually install. The custom application may be installed to the /$opkg_root/local directory, which is intended for those applications not packaged for OpenPKG installation. OpenPKG ignores anything in /$opkg_root/local, so binaries and other files cannot be manipulated with the rpm command. It is less problematic to administer such a local subhierarchy if OpenPKG is allowed to finish its bootstrap before installation of foreign files into /$opkg_root/local. This topic is discussed in detail in . The Run-Command Facility $opkg_root/etc/rc $opkg_root/etc/rc.conf %config and %common subdirectories provides start/stop option like cron RCs has native meta-syntax derived from RPM for priorities and shorter writing OpenPKG uses its own Run-Command (RC) facility. While inspired by the System V and NetBSD 1.5 facilities, the OpenPKG version is quite different. The script $opkg_root/etc/rc drives the installed package commands. In many cases it simply executes the command in question, passing in common arguments or parameterized data. Bootstrapping Bootstrapping Overview Bootstrapping relates to a process that is self-initiating or self-sustaining, according to modern English definitions. It is an important subject of discussion with OpenPKG, because OpenPKG's duty is to install and manage packages of software applications with no outside help. The independent nature of such a duty is not fully understood until realizing that before OpenPKG can be used to install anything, it must first install itself. For OpenPKG to install itself, the administrator uses the bootstrapping process. The amount of time that the OpenPKG bootstrapping process takes depends on the CPU and I/O speed of the computer under installation. The bottleneck most often encountered involves parsing and executing the Unix shell scripts openpkg-<V>-<R>.src.sh and openpkg-<V>-<R>.<arch>-<os>.<id>.sh. As of early December 2001 these files appeared as openpkg-1.0.0-1.0.0.src.sh and openpkg-1.0.0-1.0.0.src.rpm on the site ftp.openpkg.org, and their respective file sizes were 18,476 KB and 9,885 KB. This leads to question how much storage an OpenPKG installation requires. Minimally, OpenPKG requires about 20 MB just after completing the bootstrap installation process. Of course, what storage a 'typical' installation requires depends on what the administrator chooses to install after the fact. Should the administrator decide to install a 20 GB application packaged by OpenPKG, then the resulting storage requirement will be large indeed. Results of a Successful Bootstrap The bootstrap procedure has only one purpose, and that is to install a new OpenPKG instance. The bootstrap procedure accomplishes this in two stages. The first stage can be run as any user and mostly builds the tools that OpenPKG later uses (tar, shtool, bunzip...). The second part needs to be run as root however, and will alter the underlying system. Admins running intrusion detection should take note. The entry points between OpenPKG and the operating system are: Users and groups are added to /etc/passwd and /etc/group, or whichever default mechanism the corresponding platform supports. Crontab entries are made (typically to /etc/crontab) to allow subsequent OpenPKG packages to operate periodically. An init script (typically found at /etc/init.d/<prefix>), is added to start all active daemons and other OpenPKG packages at system startup. Packages can always be 'deactivated' and started or stopped manually as well. Naturally, OpenPKG will take space in the file system corresponding to the prefix given during the first bootstrap stage. After the bootstrap script finishes, the OpenPKG file hierarchy contains a directory for the database of RPM packages, and another directory for binaries including the actual RPM command for use by OpenPKG to install packaged software. A package repository also has its own directory, though it may contain only a partial list of installed packages. Packages in this directory are used only during installation and therefore are often flushed after each successful installation. Curious admins can learn more about these entry points by comparing the system before and after bootstrapping a new OpenPKG instance. In any case, the bootstrap procedure uses the information given (--prefix, --user, --group, [--rusr]...), so finding any system alterations should be easy. To learn more about arguments that the bootstrap procedure understands, see Deinstalling OpenPKG Cleanly (DeBootstrap?) Of course, OpenPKG can be deinstalled from the target system. Surprisingly, there doesn't exist any special bootstrap (or debootstrap) script to do this. Instead, to deinstall OpenPKG simply remove the package called 'openpkg' in the same way that any other package is removed (/<prefix>/bin/rpm -e openpkg). For generic instructions on deinstalling packages, see . Beware that simply removing the file hierary anchored at <prefix> will not cleanly deinstall OpenPKG, because the remaining three entry points installed by the bootstrap process will still remain (see ). Once the deinstallation finishes, the system will return to its initial state. Any exceptions to this rule are due to files manually installed or others inhibiting the removal of the complete file hierarchy. This is important for the preservation of log files or hand-modified configuration files, for example. Default File Permissions OpenPKG presents an easy bootstrap procedure, but with the cost of preservation of existing file permissions. Namely, an OpenPKG bootstrap will overwrite the file permissions of any previously laid out directories within its normal frame of control. This means that if user anobel creates and populates a hierarchy named /cw/local, then he can expect OpenPKG to change the owner, group, and permissions of the aforementioned directory during the bootstrap procedure. No files will ever be deleted or overwritten however, so in the worst case a recovery operation only involves restoring user, group, and permissions for files adversely affected. This problem can only arise if a user initiates an OpenPKG bootstrap operation on a directory already populated with applications. It is therefore recommendable to backup such a hierarchy before running the OpenPKG bootstrap on it. Also, bootstrapping an already established OpenPKG instance is strange and not advised for just these reasons. After the bootstrap procedure finishes, the OpenPKG hierarchy includes a $opkg_root/local directory for storage of applications not under OpenPKG's installation and runtime control, as described in . To avoid problems with runtime permissions, applications should be installed to this directory after OpenPKG establishes the hierarchy. Prerequisites Supported OS /dev/random /dev/urandom Software (see ) Diskspace X MB for /$opkg_root Fully Supported Platforms As a practicality, the current OpenPKG has been implemented to run on three (Solaris, Linux, FreeBSD) of the most commonly found Internet server platformsPrecisely, the fully supported operating systems are Sun Solaris 8/9 (SPARC64), Debian Linux 2/3 (ix86), and FreeBSD 4/5 (ix86).. These platforms fully support all functionality of OpenPKG and have native packages built to order on OpenPKG servers supplying packages to the official OpenPKG ftp server ftp://ftp.openpkg.org and web site OpenPKG. Solaris 8/9 (SPARC64) FreeBSD 4/5 (ix86) Debian Linux 2/3 (ix86) Partially Supported Platforms There are additional platforms which are only partially supported due to lack of testing resources (and number of brains and hands) at OpenPKG ground zero.The partially supported operating systems are Solaris 2.6, 7 (SPARC64) and Red Hat 7.[0-2], 8.0 (ix86).. In other words, they are not in enough day-to-day use during OpenPKG package testing to guarantee complete functionality on a regular basis. Due to mounting interest, other platforms have been tried, tested, and are in use. They are known to work, but are not offically supported for similar resource limits. Platforms such as HP-UX, Tru64, NetBSD, and OpenBSD belong to this category. RedHat 7.[0-3], 8.0 (ix86) Solaris 2.6, 7 (SPARC64) Porting to New Platforms The platform requirements of OpenPKG are independent of its use, and so the inherent operating system constraint exists regardless of installation of source or binary packages. However, the good news is that no real limitation exists for how or where OpenPKG can work. Developers have ported the OpenPKG source code from its original FreeBSD roots to many other platforms, and it should indeed be easy to port to any Unix brand of operating system. Most find that porting OpenPKG is a two step process. The first step involves porting the individual software that make up the bootstrap package 'openpkg'. The software in question is Bash, cURL, Tar, and RPM). Adding patchfiles or using shtool substitutions is sometimes needed to fix software in the bootstrap package. Additionally, the bootstrap package must succeed in adding the OpenPKG native users and groups. For more on what OpenPKG does to /etc/passwd and /etc/group, please see . Lastly, ensure that the bootstrap package is able to add its crontab entries to /etc/crontab. Fiddling with the '%pre' and '%preun' sections of the bootstrap package's specification file might be needed to fix problems with user, group, and crontab entries. As soon as the boostrap package successfully builds on the new platform, the first and most important step in porting OpenPKG is complete. OpenPKG would not be very useful without its wealth of packages. Luckily, as long as the new platform provides a fair amount of the POSIX APIs, most OpenPKG packages will work out of the box. Porting a package to a new platform is needed in the event that it doesn't build and install correctly from the start. The good news is that only a few of the hundreds of OpenPKG packages contain platform specific constructs, so whether a package builds on a new platform is largely dependent on the underlying vendor software. This means that if you can build BIND without using OpenPKG, then the 'bind' OpenPKG package builds or can be adjusted to build on a new platform. To port a problem package, try solving the problem outside of any OpenPKG context whatsoever. Once the problem is solved, go back to OpenPKG and add a patch file containg the solution to the package in question. Device Requirements /dev/random and /dev/urandom Most Solaris 8 installations do not have the pseudorandom number devices /dev/random and /dev/urandom. These devices are mandatory for several OpenPKG packages such as OpenSSH and BIND 9. To correct this, Sun provides an official patch for Solaris 8 which installs the missing devices. The patch can be downloaded at ftp://sunsolve.sun.com/pub/patches/112438-02.zip. Read the patch description file for more information. Software Requirements Internally the OpenPKG bootstrap package extends the functionality of several existing open-source technologies. In particular, it uses the vendor products Red Hat RPM, Berkeley-DB, ZLib, GNU Bzip2, GNU Gzip, GNU Tar, GNU Patch, GNU Make, GNU Bash, and cURL. To circumvent potential dependency failures, OpenPKG wraps these into every source or binary bootstrap package. This means that a system not having these tools can bootstrap an OpenPKG instance just as easily as a complete system that incidentally has the aforementioned toosl. A Classic Chicken and Egg Problem There are also tools which OpenPKG doesn't bundle but requires nevertheless. Missing any of these unbundled tools will result in a failed bootstrap from either source or binary OpenPKG packages. Once a source or binary bootstrap is successfully carried out, these unbundled tools are not needed to build and install more packages into the fresh new OpenPKG instance. There exist OpenPKG packages such as sharutils and zlib to replace the functionality offered by these unbundled tools, but cannot be built before OpenPKG is itself installed! uuencode uudecode compress (applies to OpenPKG 1.1 and older only) uncompress (applies to OpenPKG 1.1 and older only) There is another set of unbundled tools which are not required for a bootstrap from a OpenPKG binary package. Missing any of these unbundled tools will lead to failure however, if bootstrapping from a OpenPKG source package. Solaris and HPUX users should pay special attention here, because neither operating system distributes a standard compliant compiler. Also, beware of the cc that is installed by default on Solaris systems. In most cases, it is nothing more than a useless wrapper script. cc (ANSI or ISO C compiler) ar (archiver) ld (linker) as (assembler) nm (name symbol viewer) These tools are also needed to build many other OpenPKG packages, in which in most cases the BuildPreReq line of a package specification file will disclose if a toolset such as a compiler or binutils is needed. In other cases a requirement may not be explicitly stated, however. Many packages implicitly require tools like ld, nm, or ar, for example. Some of these requirements can be fulfulled by OpenPKG itself through use of the OpenPKG packages gcc and binutils, but not before OpenPKG is installed! The Most Subtle Failures A frequent cause of error involves missing one or more of such unpackaged dependencies. If an installing engineer is not very vigilent in reading the hundreds of lines of scrolling OpenPKG installation text, an error of this type can go undiscovered. This may lead to the false belief that an incomplete OpenPKG instance was correctly bootstrapped. In many such cases, an admin is misled by subsequent package build failures and wastes time looking for the source of problems in the wrong place. If such a scenario arises, one solution involves redirecting the shell output when installing OpenPKG, and later examine the captured text files for missing dependencies. The command script is usefull for capturing scrolling text, and searching for the word error helps to find missing dependencies. Requirement Exceptions There exist some exceptions to these requirements. Installation of OpenPKG on Debian Linux will fail unless GNU gettext and libpam0g-dev are installed. Also, to later build packages like j2se, the library compat-libstdc++ must exist on FreeBSD. Multiple OpenPKG Instances Because OpenPKG cares only for what it sees within its cage-like file hierarchy, it is safe to have multiple instances on a single computer. It is possible, and even common, to find multiple instances of OpenPKG in the same file system. Avoid creating OpenPKG instances within each other as such nesting is not supported and will likely cause damage to one installation or another. Storage Requirements The storage requirements of a freshly bootstrapped OpenPKG instance are not very large. A user can expect to see a $opkg_root directory size of seven and a half megabytes just after bootstrapping finishes. When choosing where to install OpenPKG for the first time, careful planning is advised. Though less than eight megabytes of storage suffice to install OpenPKG itself, subsequent installations will likely push this figure higher. Depending on how much software is installed, an OpenPKG instance can easily reach hundreds of megabytes in size! Actually, there is nothing strange about this. In fact the local software directories of most pre-bundled Unix derivatives require gigabytes of storage with full installations. $ du -h -d0 /cw 457M /cw $ Should a working instance of OpenPKG reach the limit of its intended storage, the OpenPKG instance can theoretically be moved to a different location. Such undesirable file system manipulation can however be avoided by carefully planning storage requirements as early as possible. A wise user will put OpenPKG somewhere that it can stay, even on a network file share. Such remote storage can indeed be used for an OpenPKG instance, and is often the best way to ensure a lasting installation of OpenPKG. Installing a remotely stored OpenPKG instance leads to the question of how to subsequently install and apply OpenPKG software packages. Remote Directory Linking The simplest way to use OpenPKG when its file hierarchy is on a network file share is to make a single symbolic link to a local directory, and then forever reference OpenPKG through this link. Specifically, first create a symbolic link on the local file system. Ensure that it refers to the remote location where the OpenPKG bootstrapper will lay out its hierarchy, and then use OpenPKG as usual with the local symbolic link representing the real OpenPKG's location. Note that the order of symbolic linking and then bootstrapping is significant, because during its bootstrap OpenPKG writes configuration data that hard codes the prefix pathname given on the command line. As not all users will install OpenPKG to a remote file system, using symlinks in this manner is optional. An example better explains this concept. $ mkdir /nfs/cw $ ln -s /nfs/cw /cw $ sh openpkg-1.0.0-1.0.0.src.sh --prefix=/nfs/cw --user=cw --group=cw $ Instructions to Bootstrap Follow these steps to initiate an OpenPKG bootstrap operation. Download the latest openpkg-<V>-<R>.src.sh from ftp://ftp.openpkg.org/release/<V>/SRC. As stated in , this file name may appear as openpkg-1.0.0-1.0.0.src.sh, but be sure to pay attention to the version, revision, and extension characters. Bootstrapping with the latest shell script version is desirable, and such care to details will likely pay off in the end. After the shell script download reaches completion, it must be executed by a sh-compatible shell interpreter such as sh or bash. During its execution, this script establishes the OpenPKG hierarchy. Any user can execute this shell script, by the way. While unnecessary to run as root, it does require the development tools cc(1), make(1), ar(1), ld(1), as(1), and nm(1). Have these installed along with the tools listed in before initiating the bootstrap procedure. Additionally, the $PATH system variable must reflect the location of these tools. During this stage of the bootstrap procedure, the prefix path given on the command line will be hard coded into several of OpenPKG's configuration files. For this reason, it is important to make a good OpenPKG repository pathname decision before initializing OpenPKG and bootstrapping with the pathname. An unwise choice, for example, is to use a symlink name during the bootstrap or package installation when the installed packages will be shared among several users all with different symlinks to the OpenPKG instance. The example below shows how the '--prefix' parameter is given with the boostrap shell script. After the first shell script has finished establishing the OpenPKG hierarchy, a second script named openpkg-<V>-<R>.<arch>-<os>.<id>.sh will continue where the first left off. It is not found on any ftp server or web site. Rather, the first shell script creates it on the fly. Execute this second shell script in the same way as the first, but note that unlike the first shell script, this one requires root privileges to run. It does not, however, need the development tools required by the first. Once this shell script finishes execution, OpenPKG has completed its bootstrap procedure. The following example text may further help to understand the typical steps of applying the OpenPKG bootstrap procedure as described above. $ ftp ftp.openpkg.org ftp> cd release/<V>/SRC ftp> ls openpkg-*.src.sh ftp> get openpkg-<V>-<R>.src.sh ftp> quit $ sh openpkg-<V>-<R>.src.sh --prefix=$opkg_root --user=$opkg_ugid --group=$opkg_ugid $ su - # sh openpkg-<V>-<R>.<arch>-<os>.<id>.sh # exit $ Environment Considerations Environment Overview For most OpenPKG users, the operating system environment plays an important role. Although OpenPKG works independently of any such operating system environment, setting paths and variables leads to an easier and more convenient user experience. While working within such a cooperative environment is good practice, it is in no way necessary. OpenPKG will function properly in any case. Example For example, without a devoted OpenPKG environment, a user must pay close attention to minor details such as which copy of RPM is first searched and found by the shell. This example is actually less hypothetical as it may sound, because a typical mistake made early on by unsuspecting users is to try installing a package with the typical rpm command as found on the native operating system. In the best case, no native rpm command will be found and the user will quickly recognize the error made. In the worst case, an incompatible rpm command may already be present on the target system. Though lacking the additions of the rpm bundled with OpenPKG, it will still try to install the named package(s). It will likely fail, however, without explicitly announcing the user's error. This problem is easily solved, of course. The user must either explicitly type the whole path of the rpm command bundled with OpenPKG, or set the PATH environment variable to include the special rpm command before any others. Opa Can Help OpenPKG hacker Ralf Engelschall has a small script called opa, which he copied to his Bash resource file .bashrc to simplify OpenPKG sessions. To use this script code, the command opa must be followed by the path of a valid OpenPKG instance. For example, [bash]$ opa /cw. Particularly useful with multiple OpenPKG instances, opa() can quickly change the environment to point at a new instance in few keystrokes. More information on multiple instances of OpenPKG is found in . Shell code in .bashrc file An even shorter example of such a convenience script is three lines long. Those with a good memory can even type this eval command directly into the shell. Shorter version of opa() Production Environment Equally important is the environment outside of OpenPKG. A user wishing to use the applications installed within an OpenPKG instance will need to add certain paths to the environment used in production. In the simplest case, the production environment should be aware of the binaries in /$opkg_root/bin, configuration files in /$opkg_root/etc, and libraries in /$opkg_root/lib. Should a user ever doubt the search path of a desired application, inspecting with the which command may yield an answer. For additional comfort, the which command can be piped to wc, which will return the number of paths found for the command arguments given. $ which ls cc nm | wc -l The idea here is that if we query the search path of three commands, then we should feel safe if the shell responds with three paths. Should the shell return a different number of paths, the potential for a command path conflict exists, and the environment should be reviewed. Installation of Packages Package Installation Overview On a working OpenPKG system, installation of packages is rather forward. While using RPM as its underlying installation standard, OpenPKG eases package management and administration on behalf of the user. There are source and binary packages. Choosing one of the two package forms is usually a question of platform diversity or tool availability. Should more than one platform be used at a facility, an administrator may find it wiser to download source packages. The same packages can then be installed on various platforms without returning to download. On the other hand, stripped-down servers with no programming tools cannot install such source packages. In this case, the administrator may choose platform-dependent binary packages instead. Source and Binary Packages A fundamental difference exits between an application distributed as source code, and an application (maybe the same one) first compiled and then distributed in binary form. In the first form an application in source form can be read like a book, only its language will likely be ANSI-C, Perl, or some other programming language. In the second form an application distributed as binary must first be compiled. This additional step breaks the portability of the application, because compiling it links its symbolic structure to binary libraries absolutely linked to one operating system. This limitation comes with an advantage, however. The OpenPKG administrator does not have to worry about having a compiler to match the programming language of the application's source. The common problems with assembler or linker versions also do not exist. An OpenPKG source package is easy to recognize. Its file name ends with 'src.rpm'. A binary package does not have this identifying file name postfix. Though binary packages also end with '.rpm', the name preceding '.rpm' will match the operating system that the package was compiled for. As an example, either package bison-1.29-1.src.rpm or bison-1.29-1.ix86-freebsd4.6-cw.rpm can be downloaded and installed on a computer running FreeBSD with the same end result. In either case of source or binary package installation, the administrator issues the same commands to install packages. In fact, with OpenPKG an administrator doesn't need to know the nature or contents of a package at all in order to successfully install it. Package Contents The contents of a source package include any source code and other files found in the application's original distribution, along with OpenPKG and RPM administration files. Binary packages include no source. Rather, they contain only the files written during the given application's typical course of installation, along with the same OpenPKG and RPM administration files found in the source package. Again, although installation differs for these contrasting package types, the end result is the same. Instructions to Install Fetching a Package To fetch a package from the OpenPKG package repository, start an ftp session with the host ftp.openpkg.org. Login as user anonymous and give your email address as a password. The packages available for download are located in the directories current and release, with subdirectories BIN and SRC containing binary packages and source packages, respectively. The following text describes the steps needed to fetch a source package. Fetching a binary package is very similar (different file name) and follows the same basic instructions. $ ftp ftp.openpkg.org ftp> cd release/<V>/SRC ftp> ls foo-*.src.rpm ftp> get foo-<V>-<R>.src.rpm ftp> quit $ Alternatively, packages may be downloaded via the http server on host OpenPKG. The complete URL is http://www.openpkg.org/pkg.cgi, where links exist referencing the packages stored in the ftp server's archives. The http server representation of the package repository may appeal to beginners and advanced alike, because detailed information such as dependency tree graphics is linked as reference. To actually download a package, click on its file name. To reference information such as a package's dependencies, click on 'INFO' next to the file name. Once a source package or binary package is on the local file system, further steps are required before installation succeeds. A binary package can be installed directly, but a source package must first be built into a binary package. Continue with a source package, or skip down to to directly install a binary package. For an explanation of the difference between these two package forms, please read . Building a Source Package Once fetched, a package resides on the local file system. The administrator can then install it directly if it is a binary package. However, a source package cannot be directly installed and must be built into a binary package first. The rpm command can build such a locally stored source package into a binary package as in the following example. $ rpm -Uvh foo-<V>-<R>.src.rpm $ cd $opkg_root/RPM/SRC/foo $ rpm -bb foo.spec $ A shortcut exists that is useful when a package's default implementation is adequate, and no configuration must change before compilation. To download a source package and build it in one single operation, run the following one-line command. $ rpm --rebuild ftp://ftp.openpkg.org/current/SRC/foo-<V>-<R>.src.rpm< $ Likewise, this command sequence allows for fine grain tuning of configuration and header files between the download and building stages. Its results are the same as its respective one-line command above. $ rpm -Uvh ftp://ftp.openpkg.org/current/SRC/foo-<V>-<R>.src.rpm $ cd $opkg_root/RPM/SRC/foo $ rpm -bb foo.spec $ In any case, after building a source package via the rpm command, the resulting binary package will be written to the directory $opkg_root/RPM/PKG/. This binary package can be installed to any number of target systems as long as they all share the same hardware architecture and operating system. They should also all share the same relative path name to their respective OpenPKG instances. That means that if the source package was built for the OpenPKG instance at /mycw/, the resulting binary will always install to such a directory (creating it if necessary) on any system for which it is used. These constraints along with more general security concerns make it much more appealing to build source packages on each individual system, and install the resulting binary packages only on the system where they were made. Semi-custom package building Most OpenPKG packages are made available after a close scrutiny from the OpenPKG developers leads to a level of consesus. This scrutiny involves analysis of what options the package in question offers, and which of them are most portable and most useful for typical server application. However, only one package will be available in the end. This leads to the question, "What if several configurations of the same application should be packaged?" The OpenPKG way of dealing with this issue is offering a standard configuration as well as other configurations defined in the RPM .spec file. A package builder must choose from these configuration options by adding a '--define' option to the command line while building. The configuration argument follows the aforementioned option, and the whole build command may then look something like this: $ rpm --rebuild package.src.rpm --define "with_option yes" $ This method of semi-customization works when building with '--rebuild' and '-bb' as well. Because the use of such custom definitions are not just limited to the build process, it is possible that the '--define' option variables will be used during installation as well. When in doubt, customize a package in this way by giving the same '--define' option at each step of the build and install process. For more information on how to use the custom configuration features of OpenPKG, a quick study of an RPM .spec file can yield much. Of course, choose a package which has such internal configuration variables. Search a .spec file for 'with_' to find out if the package offers such customization. This is also useful in learning which configuration options a package allows. Starting with the OpenPKG 1.1 release, all semi-custom option variables are listed in the description section of a spec file. To learn which configuration options a package offers, use the same RPM command as to view its description text. When installing packages without explicitly stating the available configuration options, defaults will be used. When the configuration option concerns extra functionality, a typical default value is to not install the extra functionality and opt for a standard installation instead. Along the same lines, OpenPKG packages with optional features are tested only through common usage and not through a rigorous and exhaustive combinational test. Although part of the release process guarantees that packages will be buildtime tested, no guarantee is implied in the building of semi-custom packages configured with options. Doing so would require an exponentially greater amount of testing (and thus exponentially longer delay in release cycle). Imagine testing each combination of just the 'apache' package with around forty options. It would cost a tester 1.1e+12 (2 ^ 40) times the amount of time and resources to conclude exhaustive testing should the tester take all options and their combinations into consideration! Multipackages Even with the flexibility offered by semi-custom package building, there are cases of additional functionality that can't be collected in a single package. The most typical example of this is if two different versions of an application must be packaged. Needless to say, the strategy of building multipackages to satisfy diverse needs is a rather complicated and somewhat dangerous one. Problems such as redundancy in package specifications, visual inconsistencies of comparable normal packages, and conflicting installation files can arise to the detriment of both the packaging and installing engineer. Because of these drawbacks, multipackages were long discouraged and didn't even exist in the package repository. Starting with OpenPKG release 1.1 they do exist, and the installing engineer can remain calm due to the following considerations made by each packager when dealing with multipackages. Multipackages are made only when absolutely necessary, and when so, a minimum number of versions will be used! This should keep down the number of multipackages in the OpenPKG package repository to just a few, or at least less than ten. Multipackages are considered only for software with major differences in vendor versions. Issues regarding minor differences or dificult upgrade paths are to be resolved without multipackaging the software. If possible, multipackages should be installable in parallel within the same OpenPKG instance. No files or paths should conflict. However, if they must conflict, the packager must provide a reasonable Conflicts: header in the RPM .spec file. If multiple versions of package 'foo' exist as multipackages, they are named 'foo' and 'fooX' where 'foo' must be the latest stable vendor version (both conditions!) Package 'fooX' can be either an older version or a newer one that is known to be unstable. The 'X' in 'fooX' is taken from the first one or two numbers of the vendor version with all punctuation stripped off. For example, some multipackages residing in the OpenPKG package repository to date are gcc2-2.95.4 and gcc-3.1, db3-3.3.11 and db-4.0.x, apache-1.3.32 and apache2-2.0.32, mysql-3.x.x and mysql4-4.0.x, and freetype1-1.3.1 and freetype-2.0.x. Installing a Binary Package Fetching and building a source package is not the same as installation. After obtaining a binary package by downloading it or fetching and building its corresponding source package, finally install it by becoming the superuser and issuing the rpm update command. $ su # rpm -Uvh $opkg_root/RPM/PGK/foo-<V>-<R>.<arch>-<os>.<id>.rpm # exit $ Configuration Configuration of OpenPKG During bootstrap, the openpkg-<V>-<R>.src.sh shell script can take several parameters. Each is an option which influences how OpenPKG is configured. --prefix=$opkg_root --user=$opkg_ugid --group=$opkg_ugid --verbose --help OpenPKG should be configured through the use of the supplied RPM macros installed at the bootstrap stage. If reconfiguration is necessary after bootstrap finishes, an experienced administrator may find configuration information stored in $opkg_root/etc, $opkg_root/var, and $opkg_root/bin amongst other places. Detailed grep usage may yield the necessary configuration information. However, if an administrator only wishes to change the user id or group, it is likely easier to reinstall OpenPKG by bootstrap while supplying the new command line arguments as usual. Configuration of Packages Once an individual package is installed, it may be configured after the fact as usual. The configuration files used by an installed package are found in $opkg_root/etc. These files are not overwritten on subsequent package updates or reinstallations. Post Installation Uninstalling a Package Uninstalling or uninstalling a package means that an installed package will be removed from the OpenPKG hierarchy. All of its binary and version-dependent files will be completely erased from storage, however its configuration files may persist. This is to ease the process of updating packages that must be uninstalled first. As with package installation, uninstallation requires superuser status. A simple one-line rpm command is all that is needed to finish the uninstallation. If any dependant package exists, OpenPKG will require that it first be removed. $ su # rpm -e foo # exit $ Updating a Package Updating or upgrading a package means that the package was previously installed, but a new version of the same package will be installed over the previous one. The previous version will cease to exist, and be replaced by the new one. A package is updated by following the same procedure described in . If the new package is a source package, then it must be built into a binary package as usual. The instructions in show how to do this. Once installation finishes, the new package will function as did the old. Furthermore, the new package will use the same configuration files as the old version did. This may be problematic if a new version changes its configuration requirements. If so, the new application is only really ready for deployment after an administrator's intervention clears up the configuration inconsistency. Information on Installed Packages Some helpful tools exist for the purpose of administering existing package installations. A good deal of information may be obtained using simple one-line rpm commands. Querying installed packages Command Result rpm -qlv foo Lists the files a package installed rpm -qi foo Informs about an installed package rpm -qa Lists all installed packages
Information on Packages Not Installed When considering a package's installation, OpenPKG can provide detailed information about the package in question. To gather information about a binary package issue the command $ rpm -qpi $opkg_root/RPM/PKG/foo-<V>-<R>.<arch>-<os>.<id>.rpm To see a list of all the files that a binary package will copy during installation, issue the command $ rpm -qplv $opkg_root/RPM/PKG/foo-<V>-<R>.<arch>-<os>.<id>.rpm Verifying an Installation RPM records summary information about each installed file and can use this information to verify the integrity of the package(s). Verifying installed packages Command Result rpm -Va Checks the integrity of all packages rpm -V foo Checks the integrity of a particular package
Developer's Guide The second part of the OpenPKG Handbook contains information helpful to an OpenPKG developer, defined as a person who specifies and creates OpenPKG packages. Developers are the target audience in this part of the handbook, although others may find such technical explanations useful in understanding the concepts of development of OpenPKG and OpenPKG packages. The Developer's Guide explains topics beyond the limited scope of of the handbook. OpenPKG RPM and Red Hat RPM OpenPKG RPM Differences OpenPKG uses RPM, the standard established by Red Hat, SuSE, and MandrakeSoft. Most RPM commands and options present in the original distribution are available to the developer, though OpenPKG goes further by supplying functionality not present in the standard RPM. For this reason, it is important to use the rpm command installed during bootstrapping, and not that of a typical default Unix distribution. Avoid the common mistake of issuing an rpm command without specifying the path first. This means that typing rpm on the command line may lead to errors, while typing $opkg_root/bin/rpm uses the correct rpm command and will succeed. Developers and users alike are recommended to make adjustments to the environment to avoid such errors. Adding $opkg_root to the $PATH is one such adjustment that will both decrease the chance of overlooking such an error and making life easier by eliminating the need to type out the full path of the rpm command during each OpenPKG operation. OpenPKG RPM Extensions OpenPKG not only includes a custom-built rpm command, but also several support scripts with utility ranging from convenience to the indispensable. When parsing a spec file, the OpenPKG rpm command executes all its shell scripts under the GNU bash command interpreter. This provides the obvious advantage of improved and more flexible scripting and command interpretation. The rpmtool Script Used often in spec files, the rpmtool shell script provides convenience to OpenPKG developers. Among many functions, it can dynamically set, replace, and manipulate platform- specific RPM variables. The OpenPKG installation or bootstrapping process copies rpmtool to $opkg_root/sbin. The shtool Script The shtoolIncidentally, shtool and OpenPKG are products of the same author, Ralf S. Engelschall. shell script is a multipurpose tool with goals similar of the rpmtool script. Namely, it makes an OpenPKG developer's life easier by facilitating the building and installation of packages through usage of its many options and arguments. A hand crafted shtool (not the one in any Unix distribution) is copied to $opkg_root/lib/rpm during installation or bootstrapping of OpenPKG. The rc Script The rc shell script found in $opkg_root/etc is a run-command facility not found in the original RPM standard. This custom OpenPKG script provides the developer with centralized and convenient application control. Required RPM Features $RPM_BUILD_ROOT shell variable The rc.d run-command facility Dynamically generated %files OpenPKG Prerequisite Certain features found in the original RPM standard are so important that OpenPKG requires their use. The build root variable $RPM_BUILD_ROOT OpenPKG requires that the developer set the build root variable before developing a new OpenPKG package. At the stage of vendor object installation, OpenPKG will read the $RPM_BUILD_ROOT variable. The variable should contain a file system path, and OpenPKG will use this path as a temporary installation area. This means that instead of installing in the target location %{l_prefix}, OpenPKG will install objects in the location specified by the build root variable. This is of course not a user's end goal, but does serve to package files according to the developer's wishes. OpenPKG will roll the RPM package from this false location to avoid disturbing or including unrelated files outside this special location. Furthermore, the packing will internally take place just as if the data were in the real installation target directory %{l_prefix}. To summarize, although the developer asks to install vendor objects to %{l_prefix}, they will install in the build root variable $RPM_BUILD_ROOT%{l_prefix}There should be no intermediate slash '/' in this line, because the variable %{l_prefix} starts with one always instead. The question is, just how can this installation redirection be achieved? Unfortunately, there are many answers. Vendors are free to use their own customary means, and often choose whichever approach is most appropriate to the particular package. Nevertheless, a few de facto standards for source trees exist, and experience shows that some approaches can be reused. Approach I: DESTDIR=$RPM_BUILD_ROOT A developer may incorporate a smart $DESTDIR variable into the Makefile of a particular package in order to accommodate the desired redirection behavior of the package. Namely, all installation paths in the Makefile will include the prepended $DESTDIR variable name which is empty by default. The result is that the developer can redirect installation from %{l_prefix} to $RPM_BUILD_ROOT%{l_prefix} by simply passing DESTDIR=$RPM_BUILD_ROOT to the make command. $ make DESTDIR=$RPM_BUILD_ROOT Note that if the Makefile is recursive and calls itself during installation, the $DESTDIR variable must be passed to any child Makefiles. Otherwise, this approach will likely fail. Approach II: AM_MAKEFLAGS="DESTDIR=$RPM_BUILD_ROOT" This approach is appropriate if the package is GNU Automake based. GNU Automake uses a $DESTDIR variable, but unfortunately does not always pass it to Makefiles recursively. Thus, approach II is not useful for recursive Makefiles. It is otherwise an attractive approach, however. The developer combines the benefits of both approaches I and II as shown. $ make DESTDIR=$RPM_BUILD_ROOT $ AM_MAKEFLAGS="DESTDIR=$RPM_BUILD_ROOT" Approach III: prefix=$RPM_BUILD_ROOT%{l_prefix} Should neither of the first two approaches suit the developer, a third build root alternative exists. The $prefix variable may be set by hand with the installation location as defined by both $RPM_BUILD_ROOT and %{l_prefix}. As GNU autoconf later parses the configuration script, the $prefix variable it will use the $prefix variable to determine where the installation later belongs. The Makefile will be written with this fixed location. This approach is friendly to recursive Makefiles, because there is no $DESTDIR variable to pass onward. $ prefix=$RPM_BUILD_ROOT%{l_prefix} Approach IV: %{l_rpmtool} subst -s A fancy approach involves the use of the rpmtool shell script. The developer employs this approach by invoking rpmtool from within the package's spec file. During OpenPKG processing of the package, the rpmtool will substitute a text pattern before installation begins. Therefore, the redirection can take place according to a location specified by the developer in the spec file. The disadvantage to this approach is that the developer must know the correct installation path beforehand, or apply a custom-built mechanism to learn it dynamically. $ %{l_rpmtool} subst -s 'pattern' Approach V: %{l_shtool} install Lastly, the shtool shell script packaged with OpenPKG is useful in such an installation redirection. When called with the install argument, it can be used to shave the hair off a duck's beak. $ %{l_shtool} install Abandoned RPM Features %ChangeLog %doc There are features in the original RPM standard which do not offer any advantages to OpenPKG. Quite contrary, they may impede OpenPKG in ways not obvious to the developer. For this reason, the features have been removed from OpenPKG's custom implementation of the rpm command. Two environment variables, %ChangeLog and %doc are also not found in OpenPKG. Attempting to use these as with the original RPM standard will result in failure. The Anatomy of a Package Package Files Before an OpenPKG package is installed, it looks like a single file with a long name. Once installation begins, OpenPKG almost magically unravels the many subcomponents of the package into a number of files that install to the specified file system. There is no magic involved, actually. OpenPKG relies on straightforward packaging technology. To better understand what happens when a user installs an OpenPKG package or manipulates an existing installation, it is useful to peruse the files that come out of such an extraction operation. Though OpenPKG can be used to package and install almost any software application, there are some typical applications worthy of further study. The following files exemplify what a user might expect to see after initiating an OpenPKG installation using the $opkg_root/bin/rpm --rebuild foo-<V>-<R>.src.rpm (from source) command. $opkg_root/RPM/SRC/foo/foo.spec $opkg_root/RPM/SRC/foo/foo-<V>.tar.gz $opkg_root/RPM/PKG/foo-<V>-<R>.<arch>-<os>.<id>.rpm $opkg_root/RPM/TMP/foo/(all the uncompressed application files) Package Specification An OpenPKG package specification file specifies the contents of a package and how it should install itself. OpenPKG not only uses spec files to install a package, but it also installs the files themselves for later reference by the OpenPKG user. A specification file describing a source package resides in $opkg_root/RPM/SRC/foo where foo is the name of the package. Incidentally, these short package names are taken from the contents of the package's spec file during installation. Many other such package attributes exist in the specification file for a package. OpenPKG RPM descriptors such as %build or %install also instruct OpenPKG how to process the package %during installation, removal, or other operations. An example is taken from the installation of GNU bison to show what exaclty a specification file specifies. The text is copied directly from the file $opkg_root/RPM/SRC/bison/bison.spec right after a default OpenPKG installation of the bison package. GNU bison specification file # package information Name: bison Summary: Yacc-compatible LALR(1) Parser Generator URL: http://www.gnu.org/software/bison/ Vendor: Free Software Foundation Packager: The OpenPKG Project Distribution: OpenPKG [REL] Group: Language License: GPL Version: 1.33 Release: 20020208 # list of sources Source0: ftp://ftp.gnu.org/gnu/bison/bison-%{version}.tar.gz # build information Prefix: %{l_prefix} BuildRoot: %{l_buildroot} BuildPreReq: OpenPKG, openpkg >= 20020206, make PreReq: OpenPKG, openpkg >= 20020206 AutoReq: no AutoReqProv: no %description Bison is a general-purpose parser generator that converts a grammar description for an LALR(1) context-free grammar into a C program to parse that grammar. Once you are proficient with bison, you may use it to develop a wide range of language parsers, from those used in simple desk calculators to complex programming languages. Bison is upward compatible with yacc: all properly- written yacc grammars ought to work with bison with no change. Anyone familiar with yacc should be able to use bison with little trouble. %prep %setup -q %build CC="%{l_cc}" \ CFLAGS="%{l_cflags -O}" \ ./configure \ --prefix=%{l_prefix} %{l_make} -f Makefile %{l_mflags} %install rm -rf $RPM_BUILD_ROOT %{l_make} -f Makefile %{l_mflags} install AM_MAKEFLAGS="DESTDIR=$RPM_BUILD_ROOT" strip $RPM_BUILD_ROOT%{l_prefix}/bin/* >/dev/null 2>&1 || true rm -f $RPM_BUILD_ROOT%{l_prefix}/info/dir rm -f $RPM_BUILD_ROOT%{l_prefix}/lib/charset.alias %{l_rpmtool} files -v -ofiles -r$RPM_BUILD_ROOT %{l_files_std} %files -f files %clean rm -rf $RPM_BUILD_ROOT Package Data Flow To better process a package under development or usage, OpenPKG abstracts the data it operates on from one packaging stage to the next. For a description of what happens at each stage of this process, see . Package Data Flow As an OpenPKG developer or user works with a package, the package's data and state undergo various changes from one stage to the next. Run-Command Scripts Though quite flexible and powerful enough to handle a variety of administrative tasks, run-command scripts can be as simple as the following example which turns on or off the IRC daemon of a server. Incidentally, this example is copied directly from an OpenPKG IRCd package installation and its default configuration files. The file is called $opkg_root/etc/ircd/ircd.conf. Unix historically intended run-command scripts to do just what this script does. To use it to turn on the ircd service, type $opkg_root/etc/rc start ircd at the shell prompt. IRC daemon run-command script #!/cw/lib/rpm/bash /cw/etc/rc ## ## rc.ircd -- Run-Commands for IRC Daemon ## %start -p 200 -u root /cw/sbin/ircd %stop -p 200 -u root kill -TERM `cat /cw/var/ircd/ircd.pid` %restart -u root kill -TERM `cat /cw/var/ircd/ircd.pid` sleep 2 /cw/sbin/ircd %reload -u root kill -HUP `cat /cw/var/ircd/ircd.pid` Reference Packages Of all the OpenPKG packagesThe official OpenPKG package repository is located on ftp://ftp.openpkg.org/, where packages are found in the directories current/SRC and release/<version>/[BIN|SRC|UPD]., some serve as good reference for developers interested in learning by example. The developer shouldn't assume that all such examples are to be followed, however. Some package specifications are rather complicated and confusing, and must be so due to their underlying build nature. Outstanding package examples Specification Nature of Example gcc Ugly because no Make variables are passed onward rpm Tricky because of bootstrap versus regular procedure dhcpd Ugly due to no exsisting standard build environment openssh Interesting for to its many transitive depencies apache Extensive due to the variety of options
Appendix The appendix of this handbook contains references for use by both users and developers. There is quite a lot of material available describing OpenPKG and helping both beginners and experienced administrators with its application. While this handbook borrows from such documents as the OpenPKG Quick Reference and OpenPKG Tutorial, it should be remembered that as with most quality Unix applications, OpenPKG installs man pages and info files. Refer to them by opening a command shell and using the command man openpkg. URL References Several URLs are useful in learning more about OpenPKG, its application, or the technology in which OpenPKG depends. OpenPKGhttp://www.openpkg.org OpenPKG FTPftp://ftp.openpkg.org Ralf S. Engelschallhttp://www.engelschall.com OpenPKG Development Teamhttp://dev.de.cw.net Cable & Wirelesshttp://www.cw.com Cable & Wireless Deutschlandhttp://www.cw.com/de Red Hat Package Managerhttp://www.rpm.org Open Sourcehttp://www.opensource.org FreeBSDhttp://www.freebsd.org Sun Solarishttp://www.sun.com/solaris Debian GNU/Linuxhttp://www.debian.org Red Hathttp://www.redhat.com Mailing Lists The OpenPKG server lists.openpkg.org makes a mailing list available for public subscription. The lists are moderated and currently have a low traffic volume. To subscribe to one of the mailing lists, send an email containing the line 'subscribe openpkg-users' (or openpkg-whatever) to petidomo@@lists.openpkg.org from whichever computer you would like to receive the mailing list messages. OpenPKG mailing lists List Name Description openpkg-announce Announcements of new packages openpkg-users Support questions and answers openpkg-bugdb Announcements of new bugs found openpkg-cvs Automated cvs commit mailouts openpkg-dev Development discussion
Usenet Newsgroups OpenPKG newsgroup articles can be found in several places. Although all may read the articles, in some newsgroups posting privileges are limited to registered readers. To post, send a message as usual and then follow the directions to register in the newsgroup. The newsgroups themselves are somewhat synchronized with what appears in the mailing lists above. You may find that your post to one or the other is replicated for readers of both usenet and email. OpenPKG newsgroups Newsgroup Name Description openpkg.announce Announcements of new packages openpkg.users Support questions and answers openpkg.bugdb Announcements of new bugs found openpkg.cvs Automated cvs commit mailouts openpkg.dev Development discussion
Environment The success of OpenPKG operations depends heavily on the proper usage of the operating system environment. While customization of OpenPKG may facilitate many routine tasks, consider standard approaches when things go awry. Lack of a variable or other small environment problem can have a negative effect on package operations. To apply the standard set of environment variables to the OpenPKG installation, see . Bugreports Should the unlikely case arise that a bug is found in the rock solid OpenPKG codebase or its packages, please quietly bring this to the attention of the OpenPKG developers by filing a bug report. The procedure is rather simple. Browse to the bug database and follow the directions there. Repository The OpenPKG repository is a place where an administrator may download OpenPKG packages. While there may be many such locations Internet wide, only one contains the official OpenPKG packages. There are many hundred such packages available at the time of publication. Package List There are quite a lot of OpenPKG source packages to select from, as the following list of hundreds of packages proves. The list includes packages under development as well as rock solid core packages. Remember that there are several package categories (CORE, BASE, PLUS, EVAL, JUNK), as well as package groups (Network, Video, Web, DNS). To obtain a current list of OpenPKG packages available as well as their attributes, read about the official OpenPKG package repository in . a2ps accent acroread adns aegis aft aica aide al amavisd amd analog ant antiword apache apache2 apg apr arpd as-cui as-gui aspell atk atool audiofile autoconf autogen automake autotrace awk axyftp bash bc bind bind8 binutils bison bochs boxes bs btyacc bzip2 c2man cadaver calamaris calc ccache ccrypt cdk cdrecord cfengine cfg cflow cftp chkrootkit cocor coreutils cpio cpu cronolog cscope curl cvs cvs2cl cvsd cvsps cvstrac cvsweb db dbtool dcoracle2 dcron ddd delegate devtodo dhcp-agent dhcpd dhcpdump dhcping di dia dialog diffstat diffutils djbdns dmalloc dnstracer docbook doclifter doxygen dsh dsniff dss dxpc easysoap emacs epm ethereal ex exim expat expect fetchmail figlet file findutils flawfinder flex fop freetype freetype1 fsl gated gawk gc gcc gcc2 gcc33 gcrypt gd gd1 gdb gdbm gdk-pixbuf gentle geoip getopt gettext ghostscript gif2png giflib gimp glark glib glib2 glimpse gmime gmp gnet gnuchess gnupg gnuplot gnutls graphviz grep grepmail groff gsoap gtk gtk2 guile gup gv gzip heise hevea hexcurse hexer honeyd htdig html2latex html2ps html2text iburg icon ifile imagemagick imap imapd imlib indent infozip inn instant integrit iozone ipaudit ircd ircii iselect ispell its4 j2ee j2se j2se14 jargon jikes jitterbug joe jpeg kerberos kermit keychain kimwitu ksh l2 lame latex2html lbreakout lcal lemon less lesstif lftp lha libdnet libevent libffi libgdome libiconv libidl libmcrypt libmikmod libnet libnids libpcap librsync libsndfile libtasn1 libtool libwmf libxml libxslt limo linc linkchecker links llgen lmtp2nntp logsurfer lout lrzsz lsof lynx lyx lzo lzop m4 magicpoint mailgrep mailsync majordomo make mapson max mc mcrypt memphis mgv mhash mhonarc mico minicom mirror mixmaster mkisofs mm mng monit mozilla mpack mpg123 mplayer msntp mtools mtr multisort multitail mutt myodbc mysql mysql4 nagios nail nano ncc ncftp ncurses neon nessus-libs netcat netpbm netrik njmc nmap nn nntpcache noweb nsd nslint nspr ntp ocaml opencdk openjade openldap openpkg-tool openpkg openpkg opensp openssh openssl openvpn oracle orbit orbit2 package pam pango par pari patch patchutils pax pb4sd pcal pccts pcre pdflib pdksh perforce perl-apache perl-ars perl-comp perl-conv perl-crypto perl-curses perl-db perl-dbi perl-dbix perl-ds perl-gd perl-gfx perl-gtk perl-inline perl-ldap perl-mail perl-net perl-ole perl-openpkg perl-parse perl-poe perl-ssl perl-sys perl-term perl-text perl-time perl-tk perl-util perl-www perl-xml perl perl56 perltidy petidomo pgautodoc pgp pgp2 php pinfo pkgconfig pks pnet pnetlib png popt portfwd portsentry poster postfix postgresql poweradmin powerdns precc prngd procmail proftpd pstoedit psutils pth pureftpd pv python qpopper qt radius ragel rc rcs rdesktop rdiff-backup rdist rdp readline recode rfc rie roadrunner rpl rrdtool rsync rt ruby rxvt sa sablotron sam2p samba samhain sasl sav saxon scanssh scli scponly screen sdl sed sendmail sfio sgml sgmlfmt sharutils shiela shtool siege sio sipcalc sitecopy skey skill slang smtpfeed snmp snort socat sox spamassassin spambouncer spegla splint spread sqlite squid ssmtp str strace stunnel styx subversion suck sudo swamp swig sysmon tar tardy tcl tcpdump tcpreplay tcsh teapop termutils tetex tex4ht texinfo tftp tidy tiff tightvnc tin tinyca tomcat-adapter tomcat tomcat4-adapter tomcat4 traceroute transfig treecc tripwire tsmc ttmkfdir txt2man txt2pdf txt2regex unison units unixodbc unrar ups uucp uudeview uvscan val valgrind var vcg vcheck vilistextum vim vorbis-libs vorbis-tools vrrpd w3m webalizer wget whatmask whois whoson wml wv x11-ssh-askpass x11 xalan-c xalan xaw3d xboard xdelta xds xemacs xerces-c xfig xine-lib xine-ui xmake xmame xmms xplanet xpm xsel xterm xv zebra zlib zsh Support OpenPKG is a collaborative open source effort. It is not a commercial product. As such, there is no single organization responsible for its technical support. However, administrators in distress may ask questions and request help from the OpenPKG mailing list or find their answer by reading through the technical information found on the OpenPKG website http://www.openpkg.org. Usenet Newsgroup Support questions can be directed to others monitoring the OpenPKG Usenet newsgroup. Please see for details. Mailing Lists Support questions can be directed to others monitoring the OpenPKG mailing list openpkg-help@@openpkg.org. Please see for details. Website URL Support, technical, and general information can be found on the OpenPKG website. Please see for details. @ 1.79 log @added Solaris 8 /dev/random notes @ text @d36 1 a36 1 July 2003 d1225 2 a1226 2 Support for /dev/random respectively /dev/urandom d1228 5 a1232 4 By default, Solaris 8 does neither /dev/random nor /dev/urandom which is mandatory for proper operations of certain packages like OpenSSH or BIND 9. In the meantime Sun provided an official patch to add the missing functionality to Solaris 8. The patch can be downloaded at d1234 3 a1236 3 ftp://sunsolve.sun.com/pub/patches/112438-02.zip. Please take a look at the patch description file first for further details. @ 1.78 log @Change demonstration prefix sfw to more classical cw, which will hopefully cause less confusion with non-OpenPKG terminology. @ text @d24 1 a24 1 Cable & Wireless Deutschland GmbH, Munich d1101 1 a1101 1 Software (see ) d1106 1 a1106 1 Diskspace X MB for /$opkg_root d1111 1 a1111 1 /dev/random d1116 1 a1116 1 /dev/urandom d1224 14 a1237 1 @ 1.77 log @Remove outdated URL to web page package area @ text @d2537 1 a2537 1 #!/sfw/lib/rpm/bash /sfw/etc/rc d2543 1 a2543 1 /sfw/sbin/ircd d2546 1 a2546 1 kill -TERM `cat /sfw/var/ircd/ircd.pid` d2549 1 a2549 1 kill -TERM `cat /sfw/var/ircd/ircd.pid` d2551 1 a2551 1 /sfw/sbin/ircd d2554 1 a2554 1 kill -HUP `cat /sfw/var/ircd/ircd.pid` @ 1.76 log @Format package list to five columns instead of six to fix alignment @ text @d36 1 a36 1 May 2003 a2629 1 Package Repositoryhttp://www.openpkg.org/pkg.cgi @ 1.75 log @More explanation about the package list @ text @d2781 1 a2781 1 @ 1.74 log @Update packages list and remember 3rd party documentation source @ text @d2771 9 a2779 4 This partial list of OpenPKG packages includes source packages and many binary packages as well. Additionally, some items have multiple package versions available. To obtain a comprehensive list of OpenPKG packages available, read about the official OpenPKG package repository in April 2003 d2778 9 d2789 1 d2792 1 d2794 8 d2805 2 d2811 1 d2814 1 d2816 2 d2819 3 d2823 7 d2831 3 d2835 3 d2840 4 d2846 2 d2849 1 d2851 2 d2854 6 d2861 1 d2863 1 d2865 7 d2873 6 a2881 1 fileutils d2883 1 d2885 1 d2887 2 d2891 1 d2893 3 d2897 7 d2906 2 d2909 1 d2911 1 d2913 4 d2918 2 d2922 1 d2924 1 d2926 1 d2928 2 d2932 2 d2935 1 d2938 5 d2944 1 d2951 1 d2953 1 d2958 6 d2965 1 d2967 1 d2969 4 d2974 4 d2979 1 d2981 5 d2987 5 d2993 3 d2997 1 d3001 2 d3004 1 d3007 1 d3011 3 d3015 1 d3017 1 d3020 2 d3023 6 d3031 1 a3031 1 mkgallery d3035 1 d3039 2 d3042 3 d3048 2 d3052 1 d3055 2 d3058 3 d3062 1 d3064 4 d3069 2 d3073 1 d3075 2 d3079 2 d3082 4 d3087 1 d3089 5 d3095 1 d3097 31 d3129 2 a3130 1 perl-addon d3132 1 d3134 1 d3137 4 d3142 2 d3145 1 d3147 4 d3154 1 d3158 2 d3162 3 d3166 5 d3173 3 d3178 6 d3185 1 d3187 5 d3193 1 a3199 1 shellutils d3203 2 d3207 1 d3211 9 d3225 3 d3229 3 d3233 1 d3236 1 d3238 1 d3241 1 d3243 2 a3244 1 textutils d3246 1 d3248 12 d3261 2 d3265 1 d3269 7 d3277 3 d3281 1 d3283 1 d3285 1 d3287 7 d3295 7 d3303 4 d3308 1 a3310 1 zope @ 1.72 log @Repair XML tag mismatch errors, replace double spaces, replace 'bootstrap process' with 'bootstrap procedure', and remove redundant bootstrap paragraph. @ text @d1169 1 a1169 1 RedHat 7.[0-2], 8.0 (ix86) @ 1.71 log @Add a section on debootstrap. @ text @d256 1 a256 1 or compilers requiring compilation. A bootstrap process is used, in d269 2 a270 10 the root cronjob (3), and the init script (4). After the bootstrap script finishes, the OpenPKG file hierarchy contains a directory for the database of RPM packages, and another directory for binaries including the actual RPM command for use by OpenPKG to install packaged software. A package repository also has its own directory, though it may contain only a partial list of installed packages. Packages in this directory are used only during installation and therefore are often flushed after each successful installation. d713 1 a713 1 They are specified during the bootstrap process of an instance. d715 1 a715 1 prefix can be specified. Existing system users can be choosen d718 1 a718 1 LDAP) account management. It's up to the administrator to d723 2 a724 2 users and groups usually map to a single pair. Please note that some software packages (i.e. sendmail, postfix) actually d727 1 a727 1 hardcoded security policies. The pay off consolidating multiple d729 1 a729 1 the inability to continue use of those applications. In fact, d736 1 a736 1 another, the gain in security is still small. To protect files d740 1 a740 1 best to dedicate a machine to development. Installing and d888 2 a889 2 OpenPKG is allowed to finish its bootstrap process before installation of foreign files into /$opkg_root/local. This topic is discussed in a943 1 d978 2 a979 2 The bootstrap process has only one purpose, and that is to install a new OpenPKG instance. The bootstrap process accomplishes this in two d985 1 a993 1 a1000 1 a1009 1 d1031 1 a1031 1 any case, the bootstrap process uses the information given d1034 1 a1034 1 bootstrap process understands, see before initiating the bootstrap process. d1441 1 a1441 1 During this stage of the bootstrap process, the prefix path given on d1461 1 a1461 1 OpenPKG has completed its bootstrap process. d1465 1 a1465 1 steps of applying the OpenPKG bootstrap process as described above. @ 1.70 log @Expand section on the bootstrap process, and relocate some text. @ text @d1014 4 a1017 3 /etc/init.d), is added to start all active daemons and other OpenPKG packages at system startup. Packages can always be 'deactivated' and started or stopped manually as well. d1050 23 d1990 1 a1990 1 however its configuration files will persist. This is to ease the d1994 2 a1995 7 uninstallation. A common mistake made by administrators is to accidentally uninstall the instance of OpenPKG itself, even with other important packages existing under its hierarchy. While this sounds serious indeed, the remedy is simple. Since it is not possible to uninstall OpenPKG to its pre-bootstrap state, just update OpenPKG by downloading the desired version and installing it like any other package. @ 1.69 log @rewrite documentation about "Userids and Groupids" @ text @d36 1 a36 1 January 2003 d266 6 a271 6 The three main points of contact at which OpenPKG interacts with the operating system are the file system (1) with its owner and group attributes from /etc/passwd, the root cronjob (2) typically modified at /etc/crontab or crontab -e, and the init script (3) usually found at /etc/init.d. After the bootstrap script d785 1 a785 1 d981 65 @ 1.68 log @correct spelling of "privileges" @ text @d719 46 a764 8 OpenPKG installs three userid and groupid pairs during bootstrap. OpenPKG is designed with good security in mind, and thus provides four userid and groupid pairs. Whereas one pair might often suffice, the four distinct pairs allow for finer granularity. In some cases, a software application will actually require a more privileged or less privileged user and group pair in addition to the normal pair. Many daemon packages use such special users and groups for improving security, for example. d773 1 a773 1 the given management user and group names as a template. d775 5 a779 4 By default, the restricted user name will match that of the management user, adding a '-r' extension. The non-privileged user name will match that of the management user, but add a '-n' extension instead. The superuser user name is 'root' by default. d781 1 a781 6 The new OpenPKG groupids are handled in the same way. For example, if an OpenPKG instance is bootstrapped to the directory called 'cw', then the four associated userids will be 'cw', 'cw-r', 'cw-n', and 'root'. The four associated groupids will be 'cw', 'cw-r', 'cw-n', and 'root' or 'wheel' (or whatever the system-particular superuser group name is). The administrator can read the unix password file d789 1 a789 1 needs of the administrator. Additional arguments may be give when d845 7 a851 5 These user and group names can be queried from within the OpenPKG specification file. The variables %{l_musr}, %{l_rusr}, and %{l_nusr} expand to the management, restricted, and non-privileged users. The variables %{l_mgrp}, %{l_rgrp}, and %{l_ngrp} expand to the management, restricted, and non-privileged groups. @ 1.67 log @Improve example opa logic with suggestion from Vinod KUTTY. @ text @d734 1 a734 1 non-priviledged user and group names, they will be determined by using d738 1 a738 1 user, adding a '-r' extension. The non-priviledged user name will match d759 1 a759 1 --rusr=<name>, the non-priviledged user with d777 1 a777 1 --nusr=<non-priviledged user name> d797 1 a797 1 --ngrp=<non-priviledged group name> d813 1 a813 1 expand to the management, restricted, and non-priviledged users. The d815 1 a815 1 management, restricted, and non-priviledged groups. @ 1.66 log @fixed compress/uncompress requirement @ text @d1419 1 a1419 1 exit 1 d1423 1 a1423 1 exit 1 @ 1.65 log @Clarify platforms and expected level of support. @ text @d1150 1 a1150 1 compress d1155 1 a1155 1 uncompress @ 1.64 log @Update supported platforms, clarify requirements, expand section 'porting'. @ text @d982 1 a982 1 (Un)officially supported OS d1007 1 a1007 1 Officially Supported Platforms d1011 8 a1018 8 server platformsPrecisely, the officially supported operating systems are Sun Solaris 9 (SPARC), Debian GNU/Linux 3.0 (ix86), Red Hat Linux 7.2 (ix86), and FreeBSD 4.7 (ix86).. These platforms fully support all functionality of OpenPKG and have native packages built to order on OpenPKG servers supplying packages to the official OpenPKG ftp server ftp://ftp.openpkg.org and web site OpenPKG. d1022 1 a1022 1 Solaris 9 (SPARC) d1027 1 a1027 1 FreeBSD 4.7 (ix86) d1032 1 a1032 6 Debian GNU/Linux 3.0 (ix86) RedHat 7.2 (ix86) d1039 1 a1039 1 Unofficially Supported Platforms d1041 4 a1044 5 There are additional platforms which are unofficially supported due to lack of testing resources (and number of brains and hands) at OpenPKG ground zero.The unofficially supported operating systems are Solaris [678] (SPARC), Solaris 8 (ix86), FreeBSD 4.[0-6] (ix86), FreeBSD 5.0 (ix86), Debian 2.2 (ix86), and Red Hat 7.[01] d1050 1 a1050 1 Such platforms as NetBSD, OpenBSD, Tru64, and HP-UX belong to this d1055 1 a1055 16 Solaris 6, 7, 8 (SPARC) Solaris 8 (ix86) FreeBSD 4.[0-6] (ix86) Debian GNU/Linux 2.2 (ix86) d1060 1 a1060 1 RedHat 7.[01] (ix86) @ 1.63 log @Add text for forgotten user and group name superuser. @ text @d44 3 a46 2 url='http://www.freebsd.org/'>FreeBSD (iX86), and Debian GNU/Linux (iX86), and is d268 11 a278 10 attributes from /etc/passwd, the root cronjob (2) typically modified at /etc/crontab or crontab -e, and the init script (3) usually found at /etc/init.d. After the bootstrap script finishes, the OpenPKG file hierarchy contains a directory for the database of RPM packages, and another directory for binaries including the actual RPM command for use by OpenPKG to install packaged software. A package repository also has its own directory, though it may contain only a partial list of installed packages. Packages in this directory are used only during installation and therefore are often flushed after each successful installation. d716 1 a716 1 d747 3 a749 2 is). The administrator can read the unix password file /etc/passwd and unix group file /etc/group to see the new entries. d1006 1 a1006 1 d1010 31 a1040 9 three of the most commonly found Internet server platforms Precisely, the officially supported operating system version numbers are Sun Solaris 2.8 (SPARC), Debian GNU/Linux 2.2 (iX86), and FreeBSD 4.[56] (iX86).. These platforms fully support all functionality of OpenPKG and have native packages built to order on OpenPKG servers supplying packages to the official OpenPKG ftp server ftp://ftp.openpkg.org and web site OpenPKG. d1043 1 a1043 1 d1046 39 a1084 11 Additionally, Solaris 2.[679] (SPARC), FreeBSD 4.[0-4] (iX86) and FreeBSD 5.0 (iX86), and Debian 3.0 (iX86) are unofficially supported due to lack of testing resources (and number of brains and hands) at OpenPKG ground zero. In other words, they are not in enough day-to-day use during OpenPKG package testing to guarantee complete functionality on a regular basis. Due to mounting interest, other platforms have been tried, tested, and are in use. They are known to work, but remain on the list of unoffically supported platforms for similar time and resource limits. These unofficially supported platforms are RedHat Linux (iX86), Mandrake Linux (iX86), Solaris (iX86), NetBSD (SPARC and iX86), OpenBSD (iX86), HP-UX (PA/IPF), and Compaq Tru64 (Alpha). d1087 2 a1088 2 Porting To New Platforms d1098 34 a1131 1 @ 1.62 log @Improve and add text to section 'Security Through Userids and Groupids'. @ text @d718 3 a720 3 OpenPKG is designed with good security in mind, and thus provides three userid and groupid pairs. Whereas one pair might often suffice, the three distinct pairs allow for finer granularity. In some cases, a d723 2 a724 2 daemon packages use the special user and group for improving security, for example. d727 13 a739 4 By default, one userid created during bootstrap has the same name as the OpenPKG instance. Another userid simply adds a '-r' extension to the first, and indicates the restricted user. The last userid adds a '-n' extension to the first, and indicates the non-priviledged user. d742 5 a746 4 the three associated userids will be 'cw', 'cw-r', and 'cw-n'. The three associated groupids will be 'cw', 'cw-r', and 'cw-n'. The administrator can read the unix password file /etc/passwd and unix group file /etc/group to see the new entries. d751 1 a751 1 This behaviour is true by default, but may be customized to suit the d753 2 a754 2 running the bootstrapper (see ) to accommodate special user and group names. Specify the name of the d756 2 a757 1 --rusr=<name>, and the non-priviledged user with --nusr=<name>. d759 1 a759 1 --rgrp=<name>, and --ngrp=<name>. d779 5 d795 5 @ 1.61 log @commit pending changes to CVS @ text @d36 1 a36 1 December 2002 d715 1 a715 1 Security through Userids and Groupids d717 75 a791 13 OpenPKG is designed with good security in mind, and thus provides three Userid and Groupid pairs. Whereas one pair might often suffice, the three distinct pairs allow for finer granularity of providing access to operating system resources. In a few cases, a software application will actually require such an abstraction of user and group rights. The first new Userid created at bootstrap time will have the same name as the OpenPKG instance. The second new Userid will resemble the first, only with a '-r' name extension meaning restricted. The third new Userid will resemble the first, only with a '-n' name extension meaning non-privileged. For example, if an OpenPKG instance is bootstrapped to the directory called 'cw', then the three associated Userids will be cw, cw-r, and cw-n. The administrator can read the Unix password file to see the new entries. d793 1 a794 5 @ 1.60 log @Reformat affected lines. @ text @d3 2 a4 2 PUBLIC '-//OASIS//DTD DocBook XML V4.1.2//EN' '/cw/share/sgml/docbook-dtd-xml/docbookx.dtd'> @ 1.59 log @Clarify entry point at /etc/passwd and update change date. @ text @d267 10 a276 10 attributes from /etc/passwd, the root cronjob (2) typically modified at /etc/crontab or crontab -e, and the init script (3) usually found at /etc/init.d. After the bootstrap script finishes, the OpenPKG file hierarchy contains a directory for the database of RPM packages, and another directory for binaries including the actual RPM command for use by OpenPKG to install packaged software. A package repository also has its own directory, though it may contain only a partial list of installed packages. Packages in this directory are used only during installation and therefore are often flushed after each successful installation. @ 1.58 log @Align text. @ text @d36 1 a36 1 November 2002 d267 1 a267 1 attributes, the root cronjob (2) typically modified at /etc/crontab or @ 1.57 log @Refine prerequisite definition. @ text @d1015 4 a1018 4 There is another set of unbundled tools which are not required for a bootstrap from a OpenPKG binary package. Missing any of these unbundled tools will lead to failure however, if bootstrapping from a OpenPKG source package. d1020 4 a1023 3 neither operating system distributes a standard compliant compiler. Also, beware of the cc that is installed by default on Solaris systems. In most cases, it is nothing more than a useless wrapper script. @ 1.56 log @Corrected, reworded, and generally improved 'software requirements' subtopic of 'bootstrapping'. @ text @d1020 1 a1020 1 neither operating system distributes a ISO standard compiler. Also, d1026 1 a1026 1 cc (compiler) @ 1.55 log @Added more detailed explanation of configuration options and their relation to release testing. @ text @d36 1 a36 1 August 2002 d976 2 a977 2 potential dependency failures, OpenPKG includes these in every source or binary OpenPKG package. This means that a system not having these d979 1 a979 1 system with the aforementioned toosl. d981 2 d985 8 a992 3 nevertheless. Missing any of these important tools will either cause an OpenPKG installation to fail abruptly, or maybe more subtly later on. a1005 5 sharutils d1014 10 d1050 9 a1058 8 A frequent cause of error involves one or more of such failing dependencies. If the installing engineer is not very vigilent in reading the hundreds of lines of scrolling OpenPKG installation text, an error of this type can go undiscovered. In many such cases, the engineer is misled and wastes time looking for the trouble source in the wrong place. If such problems arise, redirect the shell output when installing OpenPKG. Later examine the captured text files for missing dependency failures. d1060 19 d1084 2 a1085 4 are installed. Also, to later build packages like jdk-sun, the library compat-libstdc++ must exist. Particular caution goes to Solaris users who may find a cc command on a freshly installed system to be nothing more than a useless wrapper script. a1087 1 @ 1.54 log @Fix a most subtle but serious error, which caused my Apache + ModSSL problems yesterday. Add BUFSIZE problem experiences as possible text. @ text @d1497 34 a1530 9 possible that the '--define' option will be used during installation as well. When in doubt, customize a package in this way by giving the same '--define' option at each step of the build and install process. For more information on how to use the custom configuration features of OpenPKG, a quick study of an RPM .spec file can yield much. Of course, choose a package which has such internal configuration variables. Search a .spec file for 'with_' to find out if the package offers such customization. This is also useful in learning which configuration options a package allows. @ 1.53 log @Emphasized difference levels of platform support with new section titles. @ text @d1491 1 a1491 1 $ rpm --rebuild package.src.rpm --define "with_option=yes" @ 1.52 log @Corrected prerequisites according to the policy: FreeBSD 4.[0-4] und FreeBSD 5.0 ist "known to work", FreeBSD 4.[56] ist "officially supported". Debian 2.2 ist officially supported, Debian 3.0 known to work. Solaris 2.8 ist officially supported, Solaris 2.[679] ist known to work. @ text @d924 2 d937 5 d954 3 d966 1 @ 1.51 log @Added HP-UX to list of unofficially supported OS, according to information from http://www.openpkg.org/faq.html#os-support. @ text @d900 1 a900 1 FreeBSD 4.[123456], Debian GNU/Linux 2.2, Sun Solaris 2.[6789] d928 18 a945 14 numbers are Sun Solaris 2.[6789], Debian GNU/Linux 2.2, and FreeBSD 4.[123456].. Sun Solaris (SPARC), Linux (iX86), and FreeBSD (iX86) fully support all functionality of OpenPKG and have native packages built to order on OpenPKG servers supplying packages to the official OpenPKG ftp server ftp://ftp.openpkg.org and web site OpenPKG. Additionally, RedHat Linux (iX86), Mandrake Linux (iX86), Solaris (iX86), NetBSD (SPARC and iX86), OpenBSD (iX86), HP-UX (PA/IPF), and Compaq Tru64 (Alpha) operating systems are unofficially supported. In most cases, these target platforms succeeded in bootstrapping and later package installations. They remain with only unofficial support however, because they are not in enough day-to-day use during OpenPKG testing to guarantee complete functionality on a regular basis. @ 1.50 log @Added section on triple userid pair and made small corrections. @ text @d36 1 a36 1 July 2002 d910 1 a910 1 diskspace X MB for /$opkg_root d936 6 a941 6 (SPARC and iX86), OpenBSD (iX86), and Compaq Tru64 (Alpha) operating systems are unofficially supported. In most cases, these target platforms succeeded in bootstrapping and later package installations. They remain with only unofficial support however, because they are not in enough day-to-day use during OpenPKG testing to guarantee complete functionality on a regular basis. @ 1.49 log @Added section on multipackages. @ text @d222 1 a222 1 Will OpenPKG succeed where others have failed? Only time will tell, d710 3 a712 3 d714 28 a741 4 RPM Maintained @ 1.48 log @Added section on '--define' semi-customization of package building. @ text @d446 3 a448 1 resulting file structure is ready for installation. d463 3 a465 1 and installs the vendor objects. d478 3 a480 1 residual files are included in the package. d1467 60 @ 1.47 log @Fix dumb markup errors. @ text @d1002 2 d1012 1 d1413 48 a1460 1 $opkg_root/RPM/PKG/. @ 1.46 log @Update of unofficially supported platforms, URL corrections, and other improvements. @ text @d1331 1 a1331 1 url='ftp://ftp.openpkg.org/'>ftp.openpkg.org. Login as user d2102 2 a2103 2 url='ftp://ftp.openpkg.org/'>ftp://ftp.openpkg.org/, where packages are found in the directories current/SRC and @ 1.45 log @Add text defining platform requirements and update version numbers throughout. Clarify section on unofficial support. @ text @d903 9 a911 9 url='ftp://ftp.openpkg.org'>ftp://ftp.openpkg.org and web site OpenPKG. Additionally, RedHat Linux (iX86), Solaris (iX86), NetBSD (SPARC and iX86), OpenBSD (iX86), and Compaq Tru64 (Alpha) operating systems are unofficially supported. In most cases, these target platforms succeeded in bootstrapping and later package installations. They remain with only unofficial support however, because they are not in enough day-to-day use during OpenPKG testing to guarantee complete functionality on a regular basis. d919 2 a920 2 FreeBSD roots to other platforms, and it should indeed be easy to port to any Unix brand of operating system. d1330 8 a1337 7 session with the host ftp.openpkg.org. Login as user anonymous and give your email address as a password. The packages available for download are located in the directories current and release, with subdirectories BIN and SRC containing binary packages and source packages, respectively. The following text describes the steps needed to fetch a source package. Fetching a binary package is very similar (different file name) and follows the same basic d1394 1 a1394 1 $ rpm --rebuild http://www.openpkg.org/pkg/foo-<V>-<R>.src.rpm< d1403 1 a1403 1 $ rpm -Uvh http://www.openpkg.org/pkg/foo-<V>-<R>.src.rpm d2101 2 a2102 1 package repository is located on ftp://ftp.openpkg.org, where packages d2169 1 a2169 1 OpenPKG Development Teamhttp://dev.de.cw.net d2298 1 a2298 1 The OpenPKG repository @ 1.44 log @Improved section software requirements with concrete prerequisites. @ text @d870 1 a870 1 FreeBSD 4.[1234], Debian GNU/Linux 2.2, Sun Solaris 2.[678] d875 1 a875 1 cc, make, ar, ld, as, nm, ... in $PATH d885 6 a890 1 /dev/[u]random d898 5 a902 6 numbers are Sun Solaris 2.[678], Debian GNU/Linux 2.2, and FreeBSD 4.[1234].. Sun Solaris (SPARC), Linux, and FreeBSD fully support all functionality of OpenPKG and have native packages built to order on OpenPKG servers supplying packages to the official OpenPKG ftp server d1295 10 a1304 11 with 'src.rpm'. A binary package does not have this identifying file name postfix. Though binary packages also end with '.rpm', the name preceding '.rpm' will match the operating system that the package was compiled for. As an example, either package bison-1.29-1.src.rpm or bison-1.29-1.ix86-freebsd4.4-cw.rpm can be downloaded and installed on a computer running FreeBSD 4.4 with the same end result. In either case of source or binary package installation, the administrator issues the same commands to install packages. In fact, with OpenPKG an administrator doesn't need to know the nature or contents of a package at all in order to successfully install it. @ 1.43 log @Small corrections. @ text @d4 1 a4 1 '/sfw/share/sgml/docbook-dtd-xml/docbookx.dtd'> d36 1 a36 1 March 2002 d163 5 a167 5 called dpkg/apt. In the case of dpkg/apt, Debian provides desirable features by supplying tools that allow the building of an installation architecture. However, its support for multiple vendor files wrapped into one package is poor. The solution is also not as clean as desirable, as each package requires many separate files. This a260 1 a278 1 d712 1 a712 1 d714 1 a714 1 d731 1 a731 1 d733 1 a733 1 d758 1 a758 1 d760 1 a760 1 d763 1 a763 1 d765 1 a765 1 d770 1 a770 1 d772 1 a772 1 d775 1 a775 1 d777 1 a777 1 d780 1 a780 1 d782 1 a782 1 d785 1 a785 1 d788 1 a788 1 d869 1 a869 1 d871 1 a871 1 d874 1 a874 1 d876 1 a876 1 d879 1 a879 1 d881 1 a881 1 d884 1 a884 1 d886 1 a886 1 d912 2 a913 2 Dependencies d917 6 a922 7 vendor products Red Hat RPM 4.0.2, Berkeley-DB 3.2.9, ZLib 1.1.3, GNU Bzip2 1.0.1, GNU Gzip 1.3, GNU Tar 1.13.19, GNU Patch 2.5.4, GNU Make 3.79.1, GNU Bash 2.05, and cURL 7.9. Be aware that you should have these tools installed before attempting an OpenPKG bootstrap operation, or OpenPKG may fail to properly install itself. A random number generator device is also required, which must reside in /dev/random and /dev/urandom. d924 56 d1069 1 a1069 1 linkend='bstrap-depends'/> before initiating the bootstrap process. d1419 1 a1419 1 d1421 1 a1421 1 d1424 1 a1424 1 d1426 1 a1426 1 d1429 1 a1429 1 d1431 1 a1431 1 d1434 1 a1434 1 d1436 1 a1436 1 d1439 1 a1439 1 d1441 1 a1441 1 d1703 1 a1703 1 d1705 1 a1705 1 d1708 1 a1708 1 d1710 1 a1710 1 d1713 1 a1713 1 d1715 1 a1715 1 d1718 1 a1718 1 d1720 1 a1720 1 d1858 1 a1858 1 d1860 1 a1860 1 d1863 1 a1863 1 d1865 1 a1865 1 @ 1.42 log @Several types of edits made in order to respect the rules of my 'preaching' at the English Technical Writing Lecture. Now I'm not a hypocrit anymore! @ text @d200 1 a200 1 pkg_xxx are used to install and manage software. Based on this model, d1106 1 a1106 1 Shell code in .bash file @ 1.41 log @Ftp directory corrections. PR: Submitted by: Reviewed by: Approved by: Obtained from: @ text @d1 1 a1 1 d3 2 a4 2 PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" "/sfw/share/sgml/docbook-dtd-xml/docbookx.dtd"> d13 1 a13 1 d36 1 a36 1 February 2002 d40 2 a41 2 OpenPKG (pronounced "open-pee-kay-chee") is a self-contained cross-platform software packaging system for Unix d43 3 a45 3 url="http://www.sun.com/solaris">Sun Solaris (SPARC), FreeBSD (iX86), and Debian GNU/Linux (iX86), and is d48 3 a50 3 OpenPKG uses software packaging technology based on an extended version of Red Hat's popular Red Hat Package Manager (RPM, v4) and d57 1 a57 1 without root priviledges or write access to the target installation d61 1 a61 1 OpenPKG is classified as Open d63 2 a64 2 url="http://www.openpkg.org/">http://www.openpkg.org/ and ftp://ftp.openpkg.org/. Although d68 2 a69 2 url="http://dev.de.cw.net/">Development Team from the Cable & Wireless Deutschland d72 1 a72 1 url="http://www.engelschall.com/">Ralf S. Engelschall and is d80 1 a80 1 d89 1 a89 1 developer-oriented OpenPKG documentation in of d104 1 a104 1 hardware, and the diversity of such an environment often leads to a d124 1 a124 1 approach, each vendor uses their own application packaging facility. d148 1 a148 1 use by the group. To increase useability and for reasons of quality d157 1 a157 1 There exist solutions to the forementioned software installation and d162 10 a171 10 The Debian Project has delivered a software packaging implementation called dpkg/apt. In the case of dpkg/apt, an installation architecture is built by Debian supplied tools. While having some desirable features, its support for multiple vendor files wrapped into one package is poor. The solution is also not as clean as desirable, as each package requires many separate files. This introduces unneccessary risks in copying complex file groups or otherwise organizing packages. Lastly, the interface between apt and dpkg is difficult to use, and does not adequately supply the functionality needed in repeated installations. d177 6 a182 6 requires such a dramatic strip down that all but the most basic 'make' functionality is rendered useless. Additionally, Ports is mostly intended for source distribution while pkg_xxx deals with binary distributions. The interface between the two distribution models is poor, causing a user to unneccessarily choose one of the two and discard all other (quite useful) functionality. d185 1 a185 1 A coalition of linux distributors once banded together in a d188 1 a188 1 Package Manager which incidentally is used in the OpenPKG d201 8 a208 8 the higher level package management tools like web start and jump start introduce power to end users and administrators alike. Unfortunately, these solutions are not available on other platforms and are therefore unusable should a single implementation strategy be required. Even worse, the implementations are not Open Source, introducing support problems and denying access to source code should bug fixes or improvements be desired. Silicon Graphics and its IRIX operating system face similar problems. d217 1 a217 1 half-success and half-failure. The goals inherant to the OpenPKG d229 1 a229 1 immediate base of knowlege and usage. This also means that some d245 1 a245 1 in use across most linux distributions. New features have been built d250 1 a250 1 especially considering that none of its original benefits or standard d259 19 a277 15 directories and files for use by OpenPKG. The bootstrap script also establishes a sort of context or environment in which OpenPKG runs. Specifically, initial configuration involves the operating system and some of its more common control facilities. The three main points of contact at which OpenPKG interacts with the operating system are the file system (1) with its owner and group attributes, the root cronjob (2) typically modified at /etc/crontab or 'crontab -e', and the init script (3) usually found at /etc/init.d. After the bootstrap script finishes, the OpenPKG file hierarchy contains a directory for the database of RPM packages, and another directory for binarys including the actual RPM command which OpenPKG will use to install packaged software. A package repository also has its own directory, though it may contain a partial list of installed packages. Packages in this repository are used only during installation and therefore are often flushed after each successful installation. d292 6 a297 6 cases, a packaging stage can be completed by both a user and a developer. A detailed description of packaging stages is useful in understanding the course of development and usage of a typical OpenPKG package. Each of the stages in question correspond to an entry in , and can be further understood after reference to . d301 1 a301 1 d303 1 a303 1 d357 1 a357 1 Package Deinstallation d419 1 a419 1 distribution. Fortunately, these patch files are straight forward to d443 1 a443 1 Once sources are ready for building to all target platorms, the d447 2 a448 2 according a makefile of some sort, and the resulting file structure is ready for installation. d512 1 a512 1 To verify that a package has sucessfully installed and is consistent d515 2 a516 2 information reaped from such a verification is useful when debugging or correcting the installation of a problematic package. Should d521 1 a521 1 requires the full path and filename, however. d534 10 a543 11 same software application. Logically, the old application's functionality will be replaced by that of the new application. Should the user desire to keep the old package installation even as the new one is installed, modifications must be made to the package's spec file in other stages of its lifecycle (see .) Updating a package with an older version is not possible. To accomplish this, the user must first deinstall the current package, and then initiate a new installation of the older version. The following command will update a package to the version specified by the file name. OpenPKG will write over the old installations files. d550 1 a550 1 Package Deinstallation d552 1 a552 1 An OpenPKG package finishes its life at the stage of deinstallation. d556 2 a557 2 the user's filesystem. As described in , some of the deinstalled package's files d566 1 a566 1 d570 1 a570 1 d573 1 a573 1 d616 1 a616 1 hierarchy establised during the bootstrap. Careless removal or other d621 1 a621 1 any reasons for such unadvisable direct filesystem editing under an d642 1 a642 1 Strickly speaking, these pieces are the individual directories, files, d645 1 a645 1 procedes to create directories and write other data such as file d721 5 a725 5 of /$opkg_root is maintained by the 'rpm' command as it adds, updates, and removes packages. The administrator must simply issue rpm commands, and not worry about what goes where or what might or might not 'look right'. This is because according to public standards, OpenPKG maintains its hierarchy in a uniform manner. d741 1 a741 1 still exists applications that the administrator must manually d811 1 a811 1 self-sustaining, according to modern english definitions. It is an d822 3 a824 3 The bottleneck most oftenly encountered involves parsing and executing the unix shell scripts openpkg-<V>-<R>.src.sh and openpkg-<V>-<R>.<arch>-<os>.<id>.sh. As d847 1 a847 1 forementioned directory during the bootstrap process. No files will d861 1 a861 1 linkend="hierarchy-local"/>. To avoid problems with runtime d872 1 a872 1 FreeBSD 4.[123], Debian GNU/Linux 2.2, Sun Solaris 2.[678] d893 1 a893 1 three of the most commonly found internet server platforms d896 1 a896 1 4.[123].. Sun Solaris (SPARC), Linux, and FreeBSD d901 2 a902 2 url="ftp://ftp.openpkg.org">ftp://ftp.openpkg.org and web site OpenPKG. Additionally, d910 1 a910 1 to any UNIX brand of operating system. d922 2 a923 2 these tools installed before attempting a OpenPKG bootstrap operation, or OpenPKG may fail to properly install itself. A random number d987 1 a987 1 not all users will install OpenPKG to a remote filesystem, using d1002 3 a1004 3 Follow these steps to initiate a OpenPKG bootstrap operation. Download the latest openpkg-<V>-<R>.src.sh from ftp://ftp.openpkg.org/release/<V>/SRC. As stated in the . d1124 2 a1125 2 long. With a good memory, the eval command can even be used by typing this line directly into the shell. d1183 1 a1183 1 There are source and binary packages. Choosing one of the two package d1194 1 a1194 1 d1212 1 a1212 1 filename postfix. Though binary packages also end with '.rpm', the d1221 1 a1221 1 successfuly install it. d1252 1 a1252 1 needed to fetch a source package. Fetching a binary package is very d1265 2 a1266 2 host OpenPKG. The complete URL is d1281 1 a1281 1 skip down to to directly install a d1284 1 a1284 1 linkend="install-sourcebinary"/>. d1288 1 a1288 1 d1330 1 a1330 1 d1395 1 a1395 1 neccessary after bootstrap finishes, an experienced administrator may d1421 2 a1422 2 Deinstalling a Package d1424 1 a1424 1 Deinstalling or uninstalling a package means that an installed package d1428 2 a1429 2 process of updating packages that must be deinstalled first. As with package installation, deinstallation requires superuser status. A d1431 2 a1432 2 deinstallation. A common mistake made by administrators is to accidentally deinstall the instance of OpenPKG itself, even with other d1435 1 a1435 1 deinstall OpenPKG to its pre-bootstrap state, just update OpenPKG by d1461 4 a1464 4 files as the old version did. This may cause issues involving a new versions changing configuration requirements, requiring the intervention of an administration before the new application is really ready for deployment. d1552 1 a1552 1 d1562 1 a1562 1 explains topics beyond the limited scope of of d1578 1 a1578 1 during bootstrapping, and not that of a typical default unix d1580 9 a1588 8 without specifying the path first. This means that typing 'rpm' on the command line may lead to errors, while typing '$opkg_root/bin/rpm' uses the correct rpm command and will succeed. Developers and users alike are recommended to make adjustments to the environment to avoid such errors. Adding $opkg_root to the $PATH is one such adjustment that will both decrease the chance of overlooking such an error and making life easier by eliminating the need to type out the full path of the rpm command during each OpenPKG operation. d1594 1 a1594 1 OpenPKG not only includes a custom built rpm command, but also d1608 2 a1609 1 bootstrapping process copies rpmtool to $opkg_root/sbin. d1615 5 a1619 4 The shtoolIncidentally, shtool and OpenPKG are products of the same author, Ralf S. Engelschall. shell script is a multipurpose tool with goals similar of the rpmtool script. Namely, it makes an OpenPKG d1622 3 a1624 3 arguments. A hand crafted shtool (not the one in any Unix distribution) is copied to $opkg_root/lib/rpm during installation or bootstrapping of OpenPKG. d1686 6 a1691 6 This is of course not the final wish from a user's point of view, but does serve to package files which is what the developer wants. OpenPKG will roll the RPM package from this false location to avoid disturbing or including unrelated files outside this special location. Furthermore, the packing will internally take place just as if the data were in the real installation target directory d1705 1 a1705 1 de facto standards for source trees exists, and experience shows d1726 5 a1730 3 Note that if the Makefile is recursive and calls itself during installation, the $DESTDIR variable must be passed to any child Makefiles. Otherwise, this approach will likely fail. d1739 3 a1741 2 unfortunately does not always pass it to Makefiles recursively. Thus, approach II is not useful for recursive Makefiles. It is d1760 4 a1763 4 installation later belongs. The makefile will be written with this fixed location. This approach is friendly to recursive Makefiles, because there is no $DESTDIR variable to pass onward. d1781 1 a1781 1 custom built mechanism to learn it dynamically. d1838 2 a1839 2 that install to the specified filesystem. There is no magic involved, actually. OpenPKG relies on straight forward packaging technology. To d1865 1 a1865 1 files to install a package, but it also installes the files themselves d1877 1 a1877 1 exacly a specification file specifies. The text is copied directly d1956 1 a1956 1 d1959 1 a1959 1 d1980 1 a1980 1 Incidentally, this example is copied directly from a OpenPKG IRCd d2022 1 a2022 1 followed, however. Some package specifications are rather complicated d2025 1 a2025 1
d2027 1 a2027 1 d2082 1 a2082 1 Package Repositoryhttp://www.openpkg.org/pkg.cgi d2108 1 a2108 1 d2154 1 a2154 1 d2206 1 a2206 1 url="http://www.openpkg.org/bugdb.html">bug database and follow d2213 1 a2213 1 The OpenPKG repository @ 1.40 log @Some things to remember from package building, and correct indentation. PR: Submitted by: Reviewed by: Approved by: Obtained from: @ text @d36 1 a36 1 January 2001 d2009 6 a2014 6 are found in the directories current/[BIN|SRC] and release/[BIN|SRC]., some serve as good reference for developers interested in learning by example. The developer shouldn't assume that all such examples are to be followed, however. Some package specifications are rather complicated and confusing, and must be so due to their underlying build nature. @ 1.39 log @Updated bison example, and corrected l_branch variable and alignment also. PR: Submitted by: Reviewed by: Approved by: Obtained from: @ text @d417 1 a417 1 adding them to the other vendor distribution files. d626 5 a630 5 the development lab of Cable & Wireless in Munich, this naming convention is more typically attributed to the fact that all OpenPKG users live in a very cool world. Hence, "cw" is OpenPKG hacker Thomas Lotterer's friendly reminder of how cool you really are as an OpenPKG user. d1981 18 a1998 18 #!/sfw/lib/rpm/bash /sfw/etc/rc ## ## rc.ircd -- Run-Commands for IRC Daemon ## %start -p 200 -u root /sfw/sbin/ircd %stop -p 200 -u root kill -TERM `cat /sfw/var/ircd/ircd.pid` %restart -u root kill -TERM `cat /sfw/var/ircd/ircd.pid` sleep 2 /sfw/sbin/ircd %reload -u root kill -HUP `cat /sfw/var/ircd/ircd.pid` @ 1.38 log @Fixed bad URL. @ text @d1875 36 a1910 11 # package information Name: bison Summary: Yacc-compatible LALR(1) Parser Generator URL: http://www.gnu.org/software/bison/ Vendor: Free Software Foundation Packager: The OpenPKG Project Distribution: OpenPKG [EXP] Group: Language License: GPL Version: 1.29 Release: %{l_branch}.0 d1912 14 a1925 39 # list of sources Source0: ftp://ftp.gnu.org/gnu/bison/bison-%{version}.tar.gz # build information Prefix: %{l_prefix} BuildRoot: %{l_buildroot} BuildPreReq: OpenPKG, openpkg >= 0.9-20011025.0, make PreReq: OpenPKG, openpkg >= 0.9-20011025.0 AutoReq: no AutoReqProv: no %description Bison is a general-purpose parser generator that converts a grammar description for an LALR(1) context-free grammar into a C program to parse that grammar. Once you are proficient with bison, you may use it to develop a wide range of language parsers, from those used in simple desk calculators to complex programming languages. Bison is upward compatible with yacc: all properly- written yacc grammars ought to work with bison with no change. Anyone familiar with yacc should be able to use bison with little trouble. %prep %setup -q %build CC="%{l_cc}" \ CFLAGS="%{l_cflags -O}" \ ./configure \ --prefix=%{l_prefix} %{l_make} %{l_mflags} %install rm -rf $RPM_BUILD_ROOT %{l_make} %{l_mflags} install AM_MAKEFLAGS="DESTDIR=$RPM_BUILD_ROOT" strip $RPM_BUILD_ROOT%{l_prefix}/bin/* >/dev/null 2>&1 || true rm -f $RPM_BUILD_ROOT%{l_prefix}/info/dir rm -f $RPM_BUILD_ROOT%{l_prefix}/lib/charset.alias %{l_rpmtool} files -v -ofiles -r$RPM_BUILD_ROOT %{l_files_std} d1927 1 a1927 1 %files -f files d1929 2 a1930 2 %clean rm -rf $RPM_BUILD_ROOT @ 1.37 log @Improve support table consistency, correct id labels, flush TODO work. @ text @d36 1 a36 1 December 2001 d2197 2 a2198 2 url="http://www.openpkg.org/pkg.cgi">bug database and follow the directions there. @ 1.36 log @Release and build corrections. @ text @d2087 1 a2087 1 d2097 1 a2097 1
d2102 1 a2102 1 Name d2143 33 a2175 12 openpkg.announce Announcements of new packages openpkg.users Support questions and answers openpkg.bugdb Announcements of new bugs found openpkg.cvs Automated cvs commit mailouts openpkg.dev Development discussion @ 1.35 log @White space beautification. @ text @d822 10 a831 10 of early October 2001 these files appeared as openpkg-0.9-36.src.sh and openpkg-0.9-36.src.rpm on the site ftp.openpkg.org, and their respective file sizes were 18,476 KB and 9,885 KB. This leads to question how much storage an OpenPKG installation requires. Minimally, OpenPKG requires about 20 MB just after completing the bootstrap installation process. Of course, what storage a 'typical' installation requires depends on what the administrator chooses to install after the fact. Should the administrator decide to install a 20 GB application packaged by OpenPKG, then the resulting storage requirement will be large indeed. d991 1 a991 1 $sh openpkg-0.9-20011107.0.src.sh --prefix=/cw --user=cw --group=cw d1001 1 a1001 1 ftp://ftp.openpkg.org/current/SRC. As stated in the ftp> cd current/SRC d1255 1 a1255 1 ftp> cd current/SRC d1630 1 a1630 1 d1632 1 a1632 1 d1636 1 a1636 1 d2137 4 a2140 1 the directions to register in the newsgroup. d2143 1 a2143 1 d2145 5 d2151 1 d2153 1 a2153 2 openpkg.bugdb openpkg.users @ 1.34 log @Fixed links, removed fixmes, explained sections. @ text @d40 7 a46 7 OpenPKG (pronounced "open-pee-kay-chee") is a self-contained cross-platform software packaging system for Unix computers. It is primarily maintained for Sun Solaris (SPARC), FreeBSD (iX86), and Debian GNU/Linux (iX86), and is easily portable to other Unix flavors. d49 5 a53 5 of Red Hat's popular Red Hat Package Manager (RPM, v4) and supports both source and binary packages. OpenPKG leverages these open standards to the user's benefit, and there are already over 200 OpenPKG RPM packages publicly available. d63 11 a73 11 url="http://www.openpkg.org/">http://www.openpkg.org/ and ftp://ftp.openpkg.org/. Although OpenPKG itself is licensed with BSD-style terms, resulting OpenPKG packages are still licensed according to their underlying third party license terms. OpenPKG is a project of the Development Team from the Cable & Wireless Deutschland Application Services division, located in Munich, Germany. The OpenPKG project was founded in November 2000 by Ralf S. Engelschall and is currently deployed for Cable & Wireless customers in Germany. d89 2 a90 2 developer-oriented OpenPKG documentation in of the handbook, and may benefit from reading both parts indeed. d288 2 a289 2 cases, a packaging stage can be completed by both a user and a developer. A detailed description of packaging stages is useful in d367 2 a368 2 authoring instructions are found in . d455 5 a459 5 installation. In order to facilitate later bundling of the files in the distributed package, this stage of installation must use its own directory and not $opkg_root as is usually the case. The developer therefore redirects the package to a fake installation hierarchy, and installs the vendor objects. d511 6 a516 6 information reaped from such a verification is useful when debugging or correcting the installation of a problematic package. Should there be no problems with a package installation, the verification command will exit silently. Of interest is that after a package is installed, it may be referenced by its simple prefix name as the following example shows. Reinstalling or updating the package d578 2 a579 2 package's data and state undergo various changes from one stage to the next. d604 3 a606 3 After the OpenPKG bootstrap finishes, the user can expect to see a new hierarchy of files on the file system. The variable $opkg_root will contain a path that matches whichever was given along with the d629 2 a630 2 hacker Thomas Lotterer's friendly reminder of how cool you really are as an OpenPKG user. d718 5 a722 5 of /$opkg_root is maintained by the 'rpm' command as it adds, updates, and removes packages. The administrator must simply issue rpm commands, and not worry about what goes where or what might or might not 'look right'. This is because according to public standards, OpenPKG maintains its hierarchy in a uniform manner. d737 2 a738 2 software application. While this might be a reality some day, there still exists applications that the administrator must manually d785 2 a786 1 has native meta-syntax derived from RPM for priorities and shorter writing d793 4 a796 4 different. The script $opkg_root/etc/rc drives the installed package commands. In many cases it simply executes the command in question, passing in common arguments or parameterized data. d821 2 a822 2 openpkg-<V>-<R>.<arch>-<os>.<id>.sh. As of early October 2001 these files appeared as openpkg-0.9-36.src.sh d842 4 a845 4 user anobel creates and populates a hierarchy named /cw/local, then he can expect OpenPKG to change the owner, group, and permissions of the forementioned directory during the bootstrap process. No files will ever be deleted or overwritten however, so in the worst case a d855 4 a858 4 After the bootstrap process finishes, the OpenPKG hierarchy includes a $opkg_root/local directory for storage of applications not under OpenPKG's installation and runtime control, as described in . To avoid problems with runtime d896 1 a896 1 d899 4 a902 4 OpenPKG. Additionally, NetBSD, OpenBSD, and Compaq Tru64 are unofficially supported with partial functionality. This means that to use OpenPKG, the administrator is limited to these platforms. This is true whether d918 5 a922 5 3.79.1, GNU Bash 2.05, and cURL 7.9. Be aware that you should have these tools installed before attempting a OpenPKG bootstrap operation, or OpenPKG may fail to properly install itself. A random number generator device is also required, which must reside in /dev/random and /dev/urandom. d979 8 a986 8 bootstrapper will lay out its hierarchy, and then use OpenPKG as usual with the local symbolic link representing the real OpenPKG's location. Note that the order of symbolic linking and then bootstrapping is significant, because during its bootstrap OpenPKG writes configuration data that hard codes the prefix pathname given on the command line. As not all users will install OpenPKG to a remote filesystem, using symlinks in this manner is optional. An example better explains this concept. d1001 2 a1002 2 ftp://ftp.openpkg.org/current/SRC. As stated in the , this file name may appear as d1012 4 a1015 4 these installed along with the tools listed in before initiating the bootstrap process. Additionally, the $PATH system variable must reflect the location of these tools. d1031 5 a1035 5 openpkg-<V>-<R>.<arch>-<os>.<id>.sh will continue where the first left off. It is not found on any ftp server or web site. Rather, the first shell script creates it on the fly. Execute this second shell script in the same way as the first, but note that unlike the first shell script, this one requires root d1066 2 a1067 2 easier and more convenient user experience. While working within such a cooperative environment is good practice, it is in no way necessary. d1073 3 a1075 3 For example, without a devoted OpenPKG environment, a user must pay close attention to minor details such as which copy of RPM is first searched and found by the shell. This example is actually less d1151 2 a1152 2 Should the shell return a different number of paths, the potential for a command path conflict exists, and the environment should be d1180 9 a1188 9 There are source and binary packages. Choosing one of the two package forms is usually a question of platform diversity or tool availability. Should more than one platform be used at a facility, an administrator may find it wiser to download source packages. The same packages can then be installed on various platforms without returning to download. On the other hand, stripped-down servers with no programming tools cannot install such source packages. In this case, the administrator may choose platform-dependent binary packages instead. d1196 23 a1218 22 and then distributed in binary form. In the first form an application in source form can be read like a book, only its language will likely be ANSI-C, Perl, or some other programming language. In the second form an application distributed as binary must first be compiled. This additional step breaks the portability of the application, because compiling it links its symbolic structure to binary libraries absolutely linked to one operating system. This limitation comes with an advantage, however. The OpenPKG administrator does not have to worry about having a compiler to match the programming language of the application's source. The common problems with assembler or linker versions also do not exist. An OpenPKG source package is easy to recognize. Its file name ends with 'src.rpm'. A binary package does not have this identifying filename postfix. Though binary packages also end with '.rpm', the name preceding '.rpm' will match the operating system that the package was compiled for. As an example, either package bison-1.29-1.src.rpm or bison-1.29-1.ix86-freebsd4.4-cw.rpm can be downloaded and installed on a computer running FreeBSD 4.4 with the same end result. In either case of source or binary package installation, the administrator issues the same commands to install packages. In fact, with OpenPKG an administrator doesn't need to know the nature or contents of a package at all in order to successfuly install it. d1228 3 a1230 3 source. Rather, they contain only the files written during the given application's typical course of installation, along with the same OpenPKG and RPM administration files found in the source package. d1248 4 a1251 4 packages, respectively. The following text describes the steps needed to fetch a source package. Fetching a binary package is very similar (different file name) and follows the same basic instructions. d1262 2 a1263 2 host OpenPKG. The complete URL is d1280 2 a1281 1 two package forms, please read . d1559 2 a1560 2 explains topics beyond the limited scope of of the handbook. d1591 3 a1593 3 several support scripts with utility ranging from convenience to the indispensable. When parsing a spec file, the OpenPKG rpm command executes all its shell scripts under the GNU bash command d1602 3 a1604 3 functions, it can dynamically set, replace, and manipulate platform- specific RPM variables. The OpenPKG installation or bootstrapping process copies rpmtool to $opkg_root/sbin. d1624 4 a1627 4 The rc shell script found in $opkg_root/etc is a run-command facility not found in the original RPM standard. This custom OpenPKG script provides the developer with centralized and convenient application control. d1673 16 a1688 17 variable before developing a new OpenPKG package. At the stage of vendor object installation, OpenPKG will read the $RPM_BUILD_ROOT variable. The variable should contain a file system path, and OpenPKG will use this path as a temporary installation area. This means that instead of installing in the target location %{l_prefix}, OpenPKG will install objects in the location specified by the build root variable. This is of course not the final wish from a user's point of view, but does serve to package files which is what the developer wants. OpenPKG will roll the RPM package from this false location to avoid disturbing or including unrelated files outside this special location. Furthermore, the packing will internally take place just as if the data were in the real installation target directory %{l_prefix}. To summarize, although the developer asks to install vendor objects to %{l_prefix}, they will install in the build root variable d1721 2 a1722 3 installation, the $DESTDIR variable must be passed to any child Makefiles. Otherwise, this approach will likely fail. d1729 2 a1730 2 This approach is appropriate if the package is GNU Automake based. GNU Automake uses a $DESTDIR variable, but d1733 2 a1734 2 otherwise an attractive approach, however. The developer combines the benefits of both approaches I and II as shown. d1749 6 a1754 6 configuration script, the $prefix variable it will use the $prefix variable to determine where the installation later belongs. The makefile will be written with this fixed location. This approach is friendly to recursive Makefiles, because there is no $DESTDIR variable to pass onward. d1766 7 a1772 8 the package's spec file. During OpenPKG processing of the package, the rpmtool will substitute a text pattern before installation begins. Therefore, the redirection can take place according to a location specified by the developer in the spec file. The disadvantage to this approach is that the developer must know the correct installation path beforehand, or apply a custom built mechanism to learn it dynamically. d1782 3 a1784 3 OpenPKG is useful in such an installation redirection. When called with the install argument, it can be used to shave the hair off a duck's beak. d1807 4 a1810 4 There are features in the original RPM standard which do not offer any advantages to OpenPKG. Quite contrary, they may impede OpenPKG in ways not obvious to the developer. For this reason, the features have been removed from OpenPKG's custom implementation of the d1941 2 a1942 2 next. For a description of what happens at each stage of this process, see . d2008 7 a2014 7 package repository is located on ftp://ftp.openpkg.org, where packages are found in the directories current/[BIN|SRC] and release/[BIN|SRC]., some serve as good reference for developers interested in learning by example. The developer shouldn't assume that all such examples are to be followed, however. Some package specifications are rather complicated and confusing, and must be so due to their underlying build nature. d2056 8 a2063 8 The appendix of this handbook contains references for use by both users and developers. There is quite a lot of material available describing OpenPKG and helping both beginners and experienced administrators with its application. While this handbook borrows from such documents as the OpenPKG Quick Reference and OpenPKG Tutorial, it should be remembered that as with most quality Unix applications, OpenPKG installs man pages and info files. Refer to them by opening a command shell and using the command man openpkg. d2090 6 a2095 6 The OpenPKG server lists.openpkg.org makes a mailing list available for public subscription. The lists are moderated and currently have a low traffic volume. To subscribe to one of the mailing lists, send an email containing the line 'subscribe openpkg-users' (or openpkg-whatever) to petidomo@@lists.openpkg.org from whichever computer you would like to receive the mailing list messages. d2157 2 a2158 2 environment variables to the OpenPKG installation, see . d2188 2 a2189 2 available, read about the official OpenPKG package repository in . d2415 2 a2416 2 mailing list openpkg-help@@openpkg.org. Please see for details. @ 1.33 log @Added text about bootstrap symlink order. @ text @d584 1 a584 1 d778 1 a778 1 d780 1 a780 1 FIXME? own for not touching system in every package d782 1 a782 1 d792 1 a792 1 different and consists of two parts. First the script d795 1 a795 3 passing in common arguments or parameterized data. The second part of the Run-Command facility involves FIXME! FIXME! eating soup and drinking lemonade. d917 1 a917 1 3.79.1, GNU Bash 2.05, and cURL 7.9. FIXME! Be aware that you should d919 3 a921 4 operation. OpenPKG will otherwise fail to properly install itself. Reads from a random number generator device will also occur, so such a device must be be present as well. The device in question has two forms which reside in the directories /dev/random and /dev/urandom. d1021 5 a1025 2 bootstrapping with the pathname. The example below shows how the prefix is given with the boostrap shell script. d1446 1 a1446 3 be replaced by the new one. Should the need arise for different versions of the same application to coexist harmoniously, you must ask FIXME! Ralf how many sandwiches he eats in one day. d1629 1 a1629 1 d1631 1 a1631 2 ability to use %{l_xxx [-XXX]} variables. These variables allow the developer to FIXME! eat turkey sandwiches and soup at the same time. d1784 1 a1784 1 used to FIXME! shave the hair off a duck's beak. a1847 3 FIXME!$opkg_root/ FIXME!$opkg_root/ FIXME!$opkg_root/ a1938 1 FIXME! Remove redundant graphic in one place or the other! FIXME! d2132 1 a2132 1 Usenet Newsgroup d2134 13 a2146 6 There is no Usenet newsgroup serving OpenPKG users. FIXME! OpenPKG newsgroup articles can be found at cw.de.apps.alt.openpkg. A curious reader may read the articles, but may only post to the newsgroup after being enrolled by the newsgroup administrator. To enroll in this newsgroup, post a message as usual and then follow the directions. d2157 2 a2158 11 environment variables to the OpenPKG installation, see FIXME!! . Contacts FIXME! Anybody that has problems with OpenPKG (or anything else) should call Ralf on the telephone at his home and complain loudly, in french. His telephone number is 1-800-OPEN-PEKAGE. @ 1.32 log @Minor wording improvement. @ text @d984 5 a988 6 bootstrapping is significant. To bootstrap OpenPKG and then later create a symbolic link to its remote file hierarchy is not desireable, because paths are written to OpenPKG's configuration during bootstrapping. These paths will not include the user's chosen symbolic link name, and can be a source of inconsistency within OpenPKG and its run command model. An example better explains this concept. d991 1 d1020 8 d1121 1 a1121 1 the line into the shell. @ 1.31 log @Index test, remember the glossary too. @ text @d25 1 a25 1 d30 1 a30 1 d36 1 a36 1 November 2001 a42 4 Solaris FreeBSD Linux Debian a47 5 Red Hat RPM source package binary package open standard a54 2 RPM extension specification d985 5 a989 6 create a symbolic link to its remote file hierarchy is less appealing, because paths are written to OpenPKG's configuration during bootstrapping. These paths will not include the user's chosen symbolic link name, and can be a source of inconsistency within OpenPKG and its run command model. An example better explains this concept. a2434 25 Index A Abracadabra, 138 Ahalbermarsch, 161 Aargonomia, 32 Alacarte, 179 Alamode, 172, 177 Akra, 177 Azerbaijan F FreeBSD @ 1.30 log @Minor edits, corrections, and rearrangement of TODO. @ text @d42 5 a46 1 platforms. It is currently primarily maintained for d52 5 d64 2 d2448 24 @ 1.29 log @Rewrote unclear sections. Added sections on environment, bootstrap storage requirements, nfs mount local linking strategy, cool world, and others that I've forgotten. @ text @d40 1 a40 1 OpenPKG (pronounced "Open-Pee-Kay-Gee") is d187 6 a192 6 facility. RedHat, SuSE, and MandrakeSoft distribute the RedHat Package Manager which incidentally is used in the OpenPKG implementation. However, the RPM solution lacks a larger framework for administrating an installation of applications as one software base. One cannot preview the dependencies between tools and libraries before deciding to install an application, for example. d244 1 a244 1 is based on the RPM architecture introduced by RedHat. RPM is already d667 1 a667 1 | +-rpm/-----|-rpmmacros d676 1 a676 1 |-lib/----+-rpm/-----|-rpme d917 1 a917 1 vendor products RedHat RPM 4.0.2, Berkeley-DB 3.2.9, ZLib 1.1.3, GNU d1557 1 a1557 1 OpenPKG RPM and RedHat RPM d1562 1 a1562 1 OpenPKG uses RPM, the standard established by RedHat, SuSE, and d2057 1 a2057 1 users and developers . There is quite a lot of material available d2394 1 d2430 5 @ 1.28 log @Added a section on file permissions after bootstrap, and added a section on the cool world principle. Minor style corrections. @ text @d62 1 a62 1 Source and is available from Cable & Wireless Deutschland Application Services division, located in Munich, Germany. The OpenPKG project was founded in November 2000 by d370 2 a371 2 $ vi foo.spec d390 2 a391 2 $ rpm --fetch foo.spec d408 2 a409 2 $ diff -u3 foo.orig foo > patchfile d432 2 a433 2 $ rpm -bp foo.spec d446 2 a447 2 $ rpm -bc --short-circuit foo.spec d461 2 a462 2 $ rpm -bi --short-circuit foo.spec d474 3 a476 3 $ rpm -bs foo.spec $ rpm -bb --short-circuit foo.spec d489 2 a490 2 $ scp -r user@@remote:/pkgs/foo.<V>-<R>.<arch>-<os>.<id >.rpm /mycomputer/ d501 2 a502 2 $ rpm -ivh foo.<V>-<R>.<arch>-<os>.<id >.rpm d519 2 a520 2 $ rpm -V foo d542 2 a543 2 $ rpm -Uvh foo.<V>-<R>.<arch>-<os>.<id >.rpm d558 2 a559 2 $ rpm -e foo d592 1 a592 1 Overview d594 8 a601 12 To run as independently as possible and avoid error-prone dependencies, OpenPKG creates its own file hierarchy during its bootstrap. All the universe known to OpenPKG exists only in this hierarchy, called $opkg_root in OpenPKG's run time environment. The name of the hierarchy is established during bootstrap and can be influenced by defining the configuration variable --prefix=$opkg_root. In all subsequent package installations, OpenPKG will control its repository and configuration by manipulation of data within the hierarchy. It is important to be careful when directly copying, removing, or altering files within this hierarchy for reasons of consistency within OpenPKG. The rpm command will fail, for example, should the $opkg_root/RPM or SRC directories be changed or removed. d606 2 a607 2 will contain a path that matchs whichever was given to initiate the bootstrap procedure. To learn more about the bootstrap procedure, d610 12 a621 2 d628 3 a630 2 users live in a very cool world. Hence, "cw" is a reminder of how cool you really are as an OpenPKG user. d632 2 d635 12 d648 1 a648 1 Initial OpenPKG file hierarchy a799 1 d806 1 a806 1 Overview d835 1 d928 72 a999 1 d1036 112 a1147 11 $ ftp ftp.openpkg.org ftp> cd current/SRC ftp> ls openpkg-*.src.sh ftp> get openpkg-<V>-<R>.src.sh ftp> quit $ sh openpkg-<V>-<R>.src.sh --prefix=$opkg_root --user=$opkg_ugid --group=$opkg_ugid $ su - # sh openpkg-<V>-<R>.<arch>-<os>.<id>.sh # exit $ d1163 1 a1163 1 Overview d1244 7 a1250 7 $ ftp ftp.openpkg.org ftp> cd current/SRC ftp> ls foo-*.src.rpm ftp> get foo-<V>-<R>.src.rpm ftp> quit $ d1285 5 a1289 5 $ rpm -Uvh foo-<V>-<R>.src.rpm $ cd $opkg_root/RPM/SRC/foo $ rpm -bb foo.spec $ d1296 3 a1298 3 $ rpm --rebuild http://www.openpkg.org/pkg/foo-<V>-<R>.src.rpm< $ d1305 5 a1309 5 $ rpm -Uvh http://www.openpkg.org/pkg/foo-<V>-<R>.src.rpm $ cd $opkg_root/RPM/SRC/foo $ rpm -bb foo.spec $ d1326 5 a1330 5 $ su # rpm -Uvh $opkg_root/RPM/PGK/foo-<V>-<R>.<arch>-<os>.<id>.rpm # exit $ d1426 5 a1430 5 $ su # rpm -e foo # exit $ d1497 2 a1498 2 $ rpm -qpi $opkg_root/RPM/PKG/foo-<V>-<R>.<arch>-<os>.<id>.rpm d1501 2 a1502 2 $ rpm -qplv $opkg_root/RPM/PKG/foo-<V>-<R>.<arch>-<os>.<id>.rpm d1711 2 a1712 3 $ make DESTDIR=$RPM_BUILD_ROOT d1731 3 a1733 4 $ make DESTDIR=$RPM_BUILD_ROOT \ $ AM_MAKEFLAGS="DESTDIR=$RPM_BUILD_ROOT" d1751 2 a1752 3 $ prefix=$RPM_BUILD_ROOT%{l_prefix} d1770 2 a1771 3 $ %{l_rpmtool} subst -s 'pattern' d1782 2 a1783 3 $ %{l_shtool} install @ 1.27 log @Updated publish date. @ text @d4 1 a4 1 "/cw/share/sgml/docbook-dtd-xml/docbookx.dtd"> a606 1 d608 16 a623 5 After OpenPKG has been freshly bootstrapped onto a new file system, the user can expect the following hierarchy of files to be present. The variable $opkg_root contains a path and will match whichever path was given during the bootstrap procedure. To learn more about the bootstrap procedure, please see . d696 6 a701 6 /$opkg_root/RPM, /$opkg_root/bin, and nearly every other subdirectory of /$opkg_root is maintained by the 'rpm' command as it adds, updates, and removes packages. The administrator must simply issue rpm commands, and not worry about what goes where or what might or might not 'look right'. This is because according to public standards, OpenPKG maintains its hierarchy in a uniform manner. d705 1 a705 1 d715 14 a728 8 In an ideal world, there would be an OpenPKG package for every software application. While this might be a reality some day, there still exists applications that the administrator must manually install. The custom application may be installed to the /$opkg_root/local directory, which is intended for those applications not packaged for OpenPKG installation. OpenPKG ignores anything in /$opkg_root/local, so binaries and other files cannot be manipulated with the rpm command. d814 3 d818 23 a840 2 FIXME There exist for OpenPKG a set of platform prerequisites for unknown reasons, just ask Ralf. @ 1.26 log @slight rewording, hopefully still correct English @ text @d36 1 a36 1 October 2001 @ 1.25 log @Solved one fixme by telling the administrator how to change an instance of Openpkg that is already configured from the bootstrap installation. @ text @d41 2 a42 2 a self-contained cross-platform software packaging format for Unix servers. It is currently available for d65 2 a66 2 Although OpenPKG itself is licensed with BSD-style terms, finished OpenPKG packages are also licensed according to their underlying third @ 1.24 log @typo @ text @d800 1 a800 2 unknown unknown reasons, just ask Ralf. d1150 8 a1157 1 find the configuration information stored in FIXME? $opkg_root/etc. d1166 2 a1167 2 package are found in $opkg_root/etc. These files are not overwritten on subsequent package updates or reinstallations. @ 1.23 log @typo @ text @d1520 1 a1520 1 Approach VI: %{l_rpmtool} subst -s d1634 1 a1634 1 from the file $opkg_root/RPM/SRC/bison/bison.spef @ 1.22 log @Completed Chapter 9. The Anatomy of a Package. Handbook Developer's Guide writing is finished, and editing begins. @ text @d497 1 a497 1 user issues the rpm command giving the 'i' istallation flag as an d549 1 a549 1 An OpenPKG package finishes its life at the stage of deistallation. d954 1 a954 1 A fundemental difference exits between an application distributed as @ 1.21 log @*** empty log message *** @ text @a564 3 d600 5 a604 6 In all subsequent package installations, OpenPKG will control its repository and configuration by manipulation of data within the hierarchy. It is important to be careful when directly copying, removing, or altering files within this hierarchy for reasons of consistency within OpenPKG. The rpm command will fail, for example, a606 1 d608 72 a679 4 RPM Maintained d820 1 a820 1 diskspace X MB for /cw d1588 26 a1613 1 d1619 79 a1697 2 (spec file) d1702 1 d1704 5 a1708 1 (flowchart) d1710 19 d1734 33 a1766 2 (code of rc file) @ 1.20 log @Finished chapter OpenPKG RPM and RedHat RPM. @ text @d50 1 a50 1 Red Hat Package Manager d771 7 a777 4 4.[123].. Sun Solaris, Linux, and FreeBSD fully support all functionality of OpenPKG and have native packages built to order on OpenPKG servers supplying packages to the official OpenPKG ftp server (ftp.openpkg.org) and web site (www.openpkg.org). d810 1 a810 1 ftp://ftp.openpkg.org/current/. As stated in the d834 3 a836 3 privileges to run. It does not, however, need the development tools required by the first. Once this shell script finishes execution, OpenPKG has completed its bootstrap process. d844 1 a844 1 ftp> cd current d942 6 a947 4 download are located at ftp.openpkg.org/current. The following text describes the steps needed to fetch a source package. Fetching a binary package is very similar (different file name) and follows the same basic instructions. d951 1 a951 1 ftp> cd current d958 10 a967 8 host www.openpkg.org. The complete URL is http://www.openpkg.org/pkg.cgi, where links exist referencing the packages stored in the ftp server's archives. The http server representation of the package repository may appeal to beginners and advanced alike, because detailed information such as dependency tree graphics is linked as reference. To actually download a package, click on its file name. To reference information such as a package's dependencies, click on 'INFO' next to the file name. d1329 30 d1361 1 a1361 23 Required RPM Features $RPM_BUILD_ROOT shell variable The rc.d run-command facility Dynamically generated %files OpenPKG Prerequisite d1363 30 a1392 2 Certain features found in the original RPM standard are so important that OpenPKG requires their use. d1396 1 a1396 1 The build root variable $RPM_BUILD_ROOT d1398 89 a1486 125 OpenPKG requires that the developer set the build root variable before developing a new OpenPKG package. At the stage of vendor object installation, OpenPKG will read the $RPM_BUILD_ROOT variable. The variable should contain a file system path, and OpenPKG will use this path as a temporary installation area. This means that instead of installing in the target location %{l_prefix}, OpenPKG will install objects in the location specified by the build root variable. This is of course not the final wish from a user's point of view, but does serve to package files which is what the developer wants. OpenPKG will roll the RPM package from this false location to avoid disturbing or including unrelated files outside this special location. Furthermore, the packing will internally take place just as if the data were in the real installation target directory %{l_prefix}. To summarize, although the developer asks to install vendor objects to %{l_prefix}, they will install in the build root variable $RPM_BUILD_ROOT%{l_prefix}There should be no intermediate slash '/' in this line, because the variable %{l_prefix} starts with one always instead. The question is, just how can this installation redirection be achieved? Unfortunately, it is quite difficult to answer. Vendors are free to use their own customary means, and often choose whichever approach is most appropriate to the particular package. Nevertheless, a few de facto standards for source trees exists, and experience shows that some approaches can be reused. Approach I: DESTDIR=$RPM_BUILD_ROOT A developer may incorporate a smart $DESTDIR variable into the Makefile of a particular package in order to accommodate the desired redirection behavior of the package. Namely, all installation paths in the Makefile will include the prepended $DESTDIR variable name which is empty by default. The result is that the developer can redirect installation from %{l_prefix} to $RPM_BUILD_ROOT%{l_prefix} by simply passing DESTDIR=$RPM_BUILD_ROOT to the make command. $ make DESTDIR=$RPM_BUILD_ROOT Note that if the Makefile is recursive and calls itself during installation, the $DESTDIR variable must be passed to any child Makefiles. Otherwise, this approach will likely fail. Approach II: AM_MAKEFLAGS="DESTDIR=$RPM_BUILD_ROOT" This approach is appropriate if the package is GNU Automake based. GNU Automake uses a $DESTDIR variable, but unfortunately does not always pass it to Makefiles recursively. Thus, approach II is not useful for recursive Makefiles. It is otherwise an attractive approach, however. The developer combines the benefits of both approaches I and II as shown. $ make DESTDIR=$RPM_BUILD_ROOT \ $ AM_MAKEFLAGS="DESTDIR=$RPM_BUILD_ROOT" Approach III: prefix=$RPM_BUILD_ROOT%{l_prefix} Should neither of the first two approaches suit the developer, a third build root alternative exists. The $prefix variable may be set by hand with the installation location as defined by both $RPM_BUILD_ROOT and %{l_prefix}. As GNU autoconf later parses the configuration script, the $prefix variable it will use the $prefix variable to determine where the installation later belongs. The makefile will be written with this fixed location. This approach is friendly to recursive Makefiles, because there is no $DESTDIR variable to pass onward. $ prefix=$RPM_BUILD_ROOT%{l_prefix} Approach VI: %{l_rpmtool} subst -s A fancy approach involves the use of the rpmtool shell script. The developer employs this approach by invoking rpmtool from within the package's spec file. During OpenPKG processing of the package, the rpmtool will substitute a text pattern before installation begins. Therefore, the redirection can take place according to a location specified by the developer in the spec file. The disadvantage to this approach is that the developer must know the correct installation path beforehand, or apply a custom built mechanism to learn it dynamically. $ %{l_rpmtool} subst -s 'pattern' Approach V: %{l_shtool} install Lastly, the shtool shell script packaged with OpenPKG is useful in such an installation redirection. When called with the install argument, it can be used to FIXME! shave the hair off a duck's beak. $ %{l_shtool} install d1489 1 d1491 24 a1514 25 Abandoned RPM Features %ChangeLog %doc There are features in the original RPM standard which do not offer any advantages to OpenPKG. Quite contrary, they may impede OpenPKG in ways not obvious to the developer or user. For this reason, the features have been removed from OpenPKG's custom implementation of the rpm command. Two environment variables, %ChangeLog and %doc are not found in OpenPKG. Attempting to use them as with the original RPM standard will return a failure code. d1553 42 a1594 12 Some of the available OpenPKG packages emphasize theirself and hence should be used as (good and bad) references for developers: - rpm: tricky because of bootstrap vs. regular procedure - gcc: ugly, because no passed through Make variables, "make install" depends on "make all" in subdirs, "make all" is forced if a Makefile changes and this way a subst on Makefiles compiles in temporary paths again. - apache: extensive, because of lots of optional parts - dhcpd: ugly, because no standard build environment - openssh: interesting, because has the most transitive depencies d1602 8 a1609 6 URLs, Environment, Mailinglists, Contact, Bugreports, Repository, repository URL, package list... Support mailing lists website d1611 364 a1977 1 @ 1.19 log @Added sections in chapter OpenPKG RPM Differences. @ text @d367 2 a368 1 authoring instructions are found in . d1390 10 a1399 6 A de facto standard for Makefiless is to support an DESTDIR variable which prefixes all installation paths and which is empty by default. This way one can redirect from %{l_prefix} to $RPM_BUILD_ROOT%{l_prefix} by simply passing DESTDIR=$RPM_BUILD_ROOT to the "make" command. a1400 1 d1402 2 a1403 3 $ $ $ make DESTDIR=$RPM_BUILD_ROOT d1405 4 a1408 4 But be aware that if the package consists of a recursive Makefile hierarchy, this approach only works if DESTDIR is correctly passed down to child Makefiles. If this is not the case, this approach fails. d1415 6 a1420 4 This a solution if the package is GNU Automake based. Automake supports DESTDIR, but unfortunately does not always pass it down to other Makefiles correctly. Here one combines Approach I and II. a1421 1 d1423 3 a1425 3 $ $ $ make DESTDIR=$RPM_BUILD_ROOT \ AM_MAKEFLAGS="DESTDIR=$RPM_BUILD_ROOT" d1431 11 d1443 3 d1451 11 d1463 3 d1471 4 d1476 3 d1498 8 a1505 4 Some features found in the original RPM standard do not offer any advantages to OpenPKG, and may even go as far as impeding its operation. For this reason, the features have been removed from the RPM that OpenPKG uses. @ 1.18 log @Testing new openpkg module structure and shiela.cfg. @ text @d1268 1 d1272 6 a1277 15 One important addition found only in the OpenPKG rpm command is the ability to use %{l_xxx [-XXX]} variables. These variable allow the developer to FIXME! eat turkey sandwiches and soup at the same time. The command rpmtool is also available to OpenPKG developers for FIXME! shaving the hair off a duck's beak. shtoolIncidentally, shtool and OpenPKG are both products of the same author, Ralf S. Engelschall. , a multipurpose tool to facilitate the building and installation of packages. The rc shell script found in $opkg_root/etc is a run-command facility not found in the original RPM standard. It was added to OpenPKG for centralized and convenient application control. Lastly, OpenPKG RPM executes all its shell scripts under the GNU bash command interpreter. This provides the obvious advantage of improved and more flexible scripting and command interpretation. d1279 41 d1348 1 a1348 1 that to use OpenPKG at all implies their obligatory usage. d1352 1 a1352 1 $RPM_BUILD_ROOT d1354 22 a1375 11 For OpenPKG packages it is mandatory that they use the build root feature of RPM. That is, they have to redirect the vendor installation procedure to a temporary area, provided by RPM as $RPM_BUILD_ROOT, and roll the RPM package from there. RPM internally will roll the package as the data would have stayed under the real installation area. So, although a package has to be configured and built for %{l_prefix} it has to install into $RPM_BUILD_ROOT%{l_prefix} (no intermediate slash here, because %{l_prefix} starts with one). d1378 6 a1383 7 The question is just how this redirection of the installation location can be achieved. Unfortunately there is no general solution, because every vendor uses its own individual procedure. Instead one has to choose an apropriate approach in dependency to the particular package. Nevertheless a few de-facto standards for source trees exists and experience showed that some approaches can be reused: @ 1.17 log @Very minor correction to test CVS and shiela.cfg. @ text @d586 1 a586 1 @ 1.16 log @Minor correction to test CVS and shiela.cfg. @ text @d1346 1 a1346 1 A de-facto standard for Makefiless is @ 1.15 log @fix DocBook XML markup @ text @d1250 1 a1250 1 OpenPKG RPM Differs @ 1.14 log @Completed chapters Software Packaging and OpenPKG RPM and RedHat RPM. Made general edits, corrections, and improvements throughout. @ text @d594 1 d616 3 a618 1 $opkg_root/* d635 3 a637 1 $opkg_root/local d656 3 a658 1 $opkg_root/etc/rc d661 3 a663 1 $opkg_root/etc/rc.conf d668 3 a670 1 %config and %common subdirectories d673 3 a675 1 provides start/stop option like cron RCs d678 3 a680 1 FIXME? own for not touching system in every package d683 3 a685 1 has native meta-syntax derived from RPM for priorities and shorter writing d745 3 a747 1 FreeBSD 4.[123], Debian GNU/Linux 2.2, Sun Solaris 2.[678] d750 3 a752 1 cc, make, ar, ld, as, nm, ... in $PATH d755 3 a757 1 diskspace X MB for /cw d760 3 a762 1 /dev/[u]random d871 12 a926 11 Choosing one of the two package forms is usually a question of platform diversity or tool availability. Should more than one platform be used at a facility, an administrator may find it wiser to download source packages. The same packages can then be installed on various platforms without returning to download. On the other hand, stripped-down servers with no programming tools cannot install such source packages. In this case, the administrator may choose platform-dependent binary packages instead. d1050 3 a1052 1 --prefix=$opkg_root d1055 3 a1057 1 --user=$opkg_ugid d1060 3 a1062 1 --group=$opkg_ugid d1065 3 a1067 1 --verbose d1070 3 a1072 1 --help d1293 3 a1295 1 $RPM_BUILD_ROOT shell variable d1298 3 a1300 1 The rc.d run-command facility d1303 3 a1305 1 Dynamically generated %files d1308 3 a1310 1 OpenPKG Prerequisite d1405 3 a1407 1 %ChangeLog d1410 3 a1412 1 %doc @ 1.13 log @Lifecycle is not an english word. Life cycle is correct. @ text @d36 1 a36 1 September 2001 d84 7 a90 9 The OpenPKG Handbook is divided into two parts. The first part contains user-oriented information, and the second contains developer-oriented information. Here we begin introducing OpenPKG from a user's point of view where user denotes the person who installs OpenPKG and OpenPKG RPM packages on a target machine. Persons who specify and create OpenPKG RPM packages are denoted developers. These individuals can find OpenPKG developer documentation in of this book, although they may also benefit from reading . d285 9 a293 4 The life cycle of a package can be classified into twelfe distinct steps which are performed by the package developer and/or package user. The following table summarizes the life cycle steps and assigns each step to involved party. d297 2 a298 2
Life cycle steps performed by package developer and/or user d302 3 a304 1 Life Cycle StepDeveloperUser d310 1 a310 1 mandatory- d314 1 a314 1 mandatory- d318 1 a318 1 optional- d338 1 a338 1 -mandatory d342 1 a342 1 -mandatory d346 1 a346 1 -mandatory d350 1 a350 1 -mandatory d354 1 a354 1 -mandatory d361 1 a361 6 In the following we will look in-depth at the steps in a package's life cycle. d364 4 a367 10 The first step in a package's life cycle is that the package developer has to write an RPM specification file, the so-called spec-file. Here all aspects of a package are controlled. For details have a look at in the of this book. $ vi bash.spec d369 2 d376 12 a387 10 Then the developer has to transfer the pristine vendor distribution file(s) to the local environment. In our current Internet area this usually just means that one downloads the files from the net via HTTP or FTP by means of the URLs in the package specification file. If this is not possible, one has to transfer the files manually in an apropriate way. $ rpm --fetch bash.spec d389 2 d396 21 a416 13 Sometimes the pristine vendor sources cannot be used as is for building on every platform. Then the package developer has to port the source first. For this he prepares an own set of patches, files containing a specification how to transform (or "to patch") one or more original source files (this is usually just the output of "diff -u3 foo.orig foo"). Additionally, if security problems occur in a package, the vendors often release intermediate patch files which fix the problem until a new (fixed) major version will come out later. These are again patch files, but instead of writing them, the package developer just adds them to the list of vendor distribution files. d423 7 a429 5 - extract vendor distribution file(s) - apply vendor patches - apply own patches - fix file system permissions in source tree rpm -bp bash.spec d431 2 d438 6 a443 4 - configuring the source tree for particular platform and real installation hierarchy - build objects from vendor sources rpm -bc --short-circuit bash.spec d445 2 d452 7 a458 3 - redirect package to a faked installation hierarchy - install vendor objects into faked installation hierarchy rpm -bi --short-circuit bash.spec d460 2 d467 5 a471 4 - determine package files - roll source and binary packages rpm -bs bash.spec rpm -bb --short-circuit bash.spec d473 3 d481 6 a486 3 - transfer source/binary package to target system scp ... ssh + lynx d488 2 d495 4 a498 2 - install package into installation hierarchy rpm -ivh d500 2 d507 10 a516 2 - verifiy package consistency rpm -V bash d518 2 d523 1 a523 1 Package Upgrade d525 15 a539 2 - upgrade existing package with new version rpm -Uvh d541 2 d548 8 a555 2 - deinstall package from hierarchy rpm -e bash d557 2 d562 2 a563 2 Package Dataflow a564 20 As we have described in the previous section, the package peruses lots steps in his life. The following figure illustrates this in detail. The Platform d566 19 d586 1 d637 7 a643 7 software application. While this might be a reality some day, it is unfortunate that currently there exists applications that the administrator must manually install. The custom application may be installed to the /$opkg_root/local directory, which is intended for those applications not packaged for OpenPKG installation. OpenPKG ignores anything in /$opkg_root/local, so binaries and other files cannot be manipulated with the rpm command. d688 1 a688 1 d760 1 a760 1 d782 1 a782 1 , this file name may appear as d793 1 a793 1 before initiating the bootstrap d1062 1 a1062 1 d1072 7 a1078 1 deinstallation. d1099 1 a1099 1 . If the new package is a source d1101 1 a1101 1 instructions in show how to do this. d1160 1 a1160 1 d1199 8 a1206 5 This is the the second part containing the Developer's Guide to OpenPKG. It introduces OpenPKG from a developer's point of view where developer denotes the person who creates OpenPKG RPM packages. This part builds up on of this book. d1211 1 a1211 1 RedHat RPM vs. OpenPKG RPM d1214 1 a1214 1 OpenPKG RPM Extension d1216 15 a1230 5 - %{l_xxx [-XXX]} variables - rpmtool - shtool - etc/rc facility - all shell scripts are executed under GNU bash d1232 110 a1341 1 d1343 5 a1347 9 Mandatory Used RPM Features - $RPM_BUILD_ROOT - rc.d facility - dynamically generated %files - PreReq: OpenPKG d1349 25 a1373 6 Intentionally Unused RPM Features - %ChangeLog - %doc d1379 1 a1379 1 Package Components a1383 1 ... d1387 1 a1387 1 d1390 1 a1390 1 (.spec file) d1395 1 a1395 1 Package Dataflow d1402 1 a1402 1 Writing Run-Command Scripts d1404 1 a1407 83 The RPM_BUILD_ROOT Issue For OpenPKG packages it is mandatory that they use the build root feature of RPM. That is, they have to redirect the vendor installation procedure to a temporary area, provided by RPM as $RPM_BUILD_ROOT, and roll the RPM package from there. RPM internally will roll the package as the data would have stayed under the real installation area. So, although a package has to be configured and built for %{l_prefix} it has to install into $RPM_BUILD_ROOT%{l_prefix} (no intermediate slash here, because %{l_prefix} starts with one). The question is just how this redirection of the installation location can be achieved. Unfortunately there is no general solution, because every vendor uses its own individual procedure. Instead one has to choose an apropriate approach in dependency to the particular package. Nevertheless a few de-facto standards for source trees exists and experience showed that some approaches can be reused: Approach I: DESTDIR=$RPM_BUILD_ROOT A de-facto standard for Makefiless is to support an DESTDIR variable which prefixes all installation paths and which is empty by default. This way one can redirect from %{l_prefix} to $RPM_BUILD_ROOT%{l_prefix} by simply passing DESTDIR=$RPM_BUILD_ROOT to the "make" command. $ make DESTDIR=$RPM_BUILD_ROOT But be aware that if the package consists of a recursive Makefile hierarchy, this approach only works if DESTDIR is correctly passed down to child Makefiles. If this is not the case, this approach fails. Approach II: AM_MAKEFLAGS="DESTDIR=$RPM_BUILD_ROOT" This a solution if the package is GNU Automake based. Automake supports DESTDIR, but unfortunately does not always pass it down to other Makefiles correctly. Here one combines Approach I and II. $ make DESTDIR=$RPM_BUILD_ROOT \ AM_MAKEFLAGS="DESTDIR=$RPM_BUILD_ROOT" Approach III: prefix=$RPM_BUILD_ROOT%{l_prefix} .. Approach VI: %{l_rpmtool} subst -s .. Approach V: %{l_shtool} install .. a1425 1 d1431 2 a1432 2 URLs, Environment, Mailinglists, Contact, Bugreports, Repository ... repository URL, package list d1434 3 a1436 4 Support mailing lists website ... a1437 1 @ 1.12 log @Made general edits and completed the chapters File Hierarchy, Configuration, and Post Installation. @ text @d285 1 a285 1 Package Lifecycle d287 1 a287 1 The lifecycle of a package can be classified into twelfe d290 1 a290 1 lifecycle steps and assigns each step to involved party. d295 1 a295 1 Lifecycle steps performed by package developer and/or user d299 1 a299 1 Lifecycle Step Developer User d358 1 a358 1 steps in a package's lifecycle. d364 1 a364 1 The first step in a package's lifecycle is that the package @ 1.11 log @Added back Ralf's prerequisite comments. Completed chapter Installation of Packages. Trimmed User's Guide structure. @ text @d523 1 a523 1 OpenPKG Hierarchy a525 1 RPM Maintained Part d527 30 a556 1 /cw d561 6 a566 1 Manually Maintained Part d568 8 a575 1 /cw/local d581 31 a611 13 OpenPKG uses its own Run-Command (RC) facility which is inspired by the System V RC and NetBSD 1.5 facility but with major differences. It consists of two parts: first there is a driving script PREFIX - own for not touching system in every package - combined start/stop with cron RCs - own RPM-derived meta-syntax for priorities and shorter writing, etc. - /cw/etc/rc - /cw/etc/rc.conf - %config, %common d658 14 a671 14 FreeBSD 4.[123], Debian GNU/Linux 2.2, Sun Solaris 2.[678] cc, make, ar, ld, as, nm, ... in $PATH diskspace X MB for /cw /dev/[u]random d853 1 a853 1 ftp> get openpkg-<V>-<R>.src.rpm d878 1 a878 1 d941 39 d981 6 a986 10 Options OpenPKG is best configured through use of RPM macros installed at the bootstrap stage. Current vs. Stable rpmmacros (RPM repositories, distfiles repository) shell environment for users d995 1 a995 1 Package Installation d997 8 a1004 1 (description, sample) d1006 5 d1014 1 a1014 1 Package Information Querying d1016 18 d1038 31 a1068 3 Package Installation Verification d1072 11 a1082 2 Package Upgrade d1087 1 a1087 1 Package Deinstallation d1089 24 a1112 1 @ 1.10 log @Completed chapter Bootstrapping. @ text @d120 2 a121 2 on the filesystem path of a software installation base. The groups may have different goals, and any flexible installation standard would d266 1 a266 1 filesystem (1) with its owner and group attributes, the root cronjob d418 1 a418 1 - fix filesystem permissions in source tree d580 10 a589 10 As of early October 2001, these files appeared as openpkg-0.9-36.src.sh and openpkg-0.9-36.src.rpm on the site ftp.openpkg.org. Their respecive file sizes were 18,476 KB and 9,885 KB. This leads to question how much storage an OpenPKG installation requires. Minimally, OpenPKG requires about 20 MB just after completing the bootstrap installation process. Of course, what storage a 'typical' installation requires depends on what the administrator chooses to install after the fact. Should the administrator decide to install a 20 GB application packaged by OpenPKG, then the resulting storage requirement will be large indeed. d599 15 a613 1 Platform Prerequisites d634 2 a635 2 Internal Dependencies d651 1 a651 1 Bootstrap Operation d667 1 a667 1 before initiating the bootstrap d697 1 a697 2 $ _ d704 8 d715 162 a876 2 Packages get installed by sticking your thumb in the sink-hole. d878 1 a878 2 Installation Steps d880 2 a881 24 Fetching Sources ... Start from Source sh *.sh --prefix \ {} < > / & (options, 3 files, etc.) Start (Over) from Binary sh *.sh d884 5 a888 1 OpenPKG Configuration d896 4 d902 5 a906 1 Working with Packages d908 5 a912 6 Package Installation (description, sample) d914 5 a918 5 Package Information Querying d920 5 a924 17 Package Installation Verification Package Upgrade Package Deinstallation d926 4 @ 1.9 log @Completed chapter 1 text, mostly introductory material with some facts that still need verification. @ text @d30 4 a39 1 a59 1 d67 7 a73 9 party license terms. OpenPKG is a project of the Development Team from the Cable & Wireless Deutschland Application Services division, located in Munich, Germany. The OpenPKG project was founded in November 2000 by Ralf S. Engelschall and is currently deployed for Cable & Wireless customers in Germany. d152 1 a152 1 available to others as open source. d207 1 a207 1 required. Even worse, the implementations are not open source, d226 1 a226 1 decision. OpenPKG is open source, meaning that its source code is not d232 1 a232 1 typical hurdles experienced by many other open source projects will d562 1 a562 1 d565 120 a684 2 what is bootstrapping, how long it takes, why platform prequiresits, etc. d686 4 d692 1 a692 1 Prerequisites d694 1 a694 7 (from binary + source) - platform FreeBSD 4.[123], Debian GNU/Linux 2.2, Sun Solaris 2.[678] - tools in $PATH cc, make, ar, ld, as, nm,... - diskspace X MB for /cw - /dev/[u]random a696 1 @ 1.8 log @Wrote part of chapter 1, using probably too much passive voice. @ text @d115 11 a125 11 anticipate. Failures may reduce production or cause unnecessary delays. More concern must be given to the potential data hazards and security risks introduced by the ad-hoc solutions mixed together when no installation standard exists. An example of such a situation occurs when complexity mounts and two groups disagree on the filesystem path of a software installation base. The groups may have different goals, and any flexible installation standard would accommodate such diverging needs. A software installation base may have vendor applications, proprietary applications, or a combination of both. In these cases, the method of administrating the installation base of computing resources makes quite a difference. In the classical d150 2 a151 2 use by the group. To strengthen such a standard and for reasons of quality assurance, the implementation of these requirements should be d159 52 a210 12 requirements not fulfilled: - Debian dpkg/apt: - bad support for N vendor files into 1 package - each package requires lots of seperate files - apt vs. dpkg is a bad interface - FreeBSD ports/pkg_xxx: - very BSD specific and hence not easily portable - after reducing non-portable things, only Make functionality remains - ports mainly for source, pkg_xxx only for binaries is bad interface - RedHat/SuSE/Mandrake RPM: - IRIX/Solaris pkgxxx: - not available as Open Source d217 59 a275 11 - use RPM and extend it with additional features - bundle RPM and essential tools into a bootstrap package - let the bootstrap package create own self-contained hierarchy - linked into system at 4 points: o filesystem owner/group (passwd+group) o root cronjob (/etc/crontab or crontab -e) o init script (/etc/init.d/, etc.) - contains RPM DB and already RPM installed into it - overview/feature-list: RPM, packages, repository, sample, benefits, - at C&W: cw:cw and /cw @ 1.7 log @Preliminary editing. @ text @d92 1 a92 1 reading part I. d100 1 a100 1 Starting Situation d102 6 a107 4 - different hardware platforms - different operating systems - different amount of installed applications - different engineer skills and preferences d112 1 a112 1 Resulting Problems d114 18 a131 7 - different configurations - different filesystem paths - some vendor applications, some own applications - each vendor uses own application packaging facility - long installation time - local engineer HOWTOs - upgrading trouble in case of problems (security, etc.) d136 1 a136 1 Requirements d138 15 a152 11 - time reduction in installation - time reduction in configuration - reasonable defaults - time reduction in maintainance - easy verification - easy upgrading - correct deinstallation - same installation results cross-platform and cross-engineer - reproducable installation - cross-platform - fully Open Source @ 1.6 log @revamp OpenPKG handbook sources and build environment @ text @d13 1 a13 1 d32 1 a32 1 June 2001 d37 5 a41 6 OpenPKG (pronounced "Open-Pee-Kay-Gi") is a self-contained cross-platform software packaging facility for Unix servers. It is currently available for Sun Solaris (SPARC), FreeBSD (iX86) and d43 1 a43 1 (iX86) and is easily portable to other Unix flavors. d45 11 a55 12 The underlying software packaging technology is based on an extended version of the popular RedHat Package Manager (RPM, v4) and supports both source and binary packages. Currently already over 170 OpenPKG RPM packages are available. The OpenPKG RPM packages are based on very clean and short RPM package specifications (possible through the unique OpenPKG extensions to RPM) and are throughout buildable both under non-root priviledges and without write-access to the target installation hierarchy. d59 2 a60 2 OpenPKG is available as Open Source from ftp://ftp.openpkg.org/ under the original licenses of the underlying third-party packages. All remaining parts developed for OpenPKG are licensed under a BSD-style license. OpenPKG is a project of the Development Team from Cable & Wireless Deutschland's Application Services division, located in Munich, Germany. The OpenPKG project was founded in November 2000 by Ralf S. Engelschall and currently is (as of June 2001) in its deploying phase for Cable & Wireless customers in Germany. d84 9 a92 8 This is the the first part, containing the User's Guide to OpenPKG. It introduces OpenPKG from a user's point of view where user denotes the person who installs OpenPKG and OpenPKG RPM packages on a target machine. Persons who create OpenPKG RPM packages are denoted developers in our context. These individuals will find their OpenPKG documentation in of this book, although they are entitled to also read this first part before, too. @ 1.5 log @remember new rc.conf stuff @ text @d400 1 a400 1 d403 1 a403 1 @ 1.4 log @update URL @ text @d440 1 a440 1 the System V RC facility but with major differences. It consists d448 3 a450 1 /cw/etc/rc @ 1.3 log @flush pending work @ text @d5 1 a5 1 @ 1.2 log @*** empty log message *** @ text @d5 1 d8 1 a8 1 a10 1 d102 1 a102 1 Starting Situation and Problem d104 6 a109 40 At Cable & Wireless Deutschland (and also already at the formerly company ECRC Internet Solutions), the Hosting team since years was faced with two major problems: After a customer ordered a new dedicated server machine, an Internet Engineer has to install the operating system, followed by the installation and configuration of the various requested Internet Service applications. This procedure usually requires up to one week of manpower and happens multiple times each month. The problems are obvious: it takes too long and the result is different every time (filesystem paths, default configuration, etc), because the procedure is not automated and the technical skill and preferences for details between the individual Internet Engineers differs dramatically. After a trouble ticket for a customer server was received, an Internet Engineer has to fix the problem. For this he locates the machine, logs into it, locates the involved Internet Service applications and their configuration files and then adjusts the configuration, upgrades a piece of software, etc. The problem here are: because of different installations it costs already extra time to locate the involved parts of the application installation .. ... d111 10 a121 1 d127 11 a137 2 time reduction, same results, reproducable, cross-platform solution, Open Source, etc. d144 12 a155 2 args why not because at least 1 requirements not fulfilled: Debian, FreeBSD ports, Stampede, etc. d162 11 a172 3 overview/feature-list: RPM, packages, repository, sample, benefits, why own hierarchy, why we touch only 3 things outside, why /cw and not /usr/local, /opt, stable/current branch, etc. d184 154 a337 6 The lifecycle of a package consists of a development part and a user part, i.e., steps which are performed by developers and optionally usonly, followed by steps which are perfromed includes the following milestones: d340 1 a340 1 Specification d342 4 a345 1 .. d350 1 a350 1 Fetching d352 3 a354 1 .. d359 1 a359 1 Preparation d361 2 a362 1 .. d367 1 a367 1 Building d369 2 a370 1 .. d375 1 a375 1 Installation d377 2 a378 1 .. d383 1 a383 1 Packaging d385 2 a386 1 .. d392 1 a392 1 Package Control-Flow d394 4 d575 5 a579 2 rpmtool, l_xxx, ... (%{l_xxx}, rpmtool, shtool, etc.) d584 1 a584 1 Intentionally Unused RPM Features d586 4 a589 1 %ChangeLog, %doc d594 1 a594 1 Mandatory Used RPM Features d596 2 a597 1 $RPM_BUILD_ROOT d613 1 a613 1 d636 95 a730 2 - prefix=, DESTDIR, AM_MAKEFLAGS, rpmtool subst, shtool install - samples @ 1.1 log @switch to DocBook XML @ text @d4 8 a11 10 "/cw/share/sgml/docbook-dtd-xml/docbookx.dtd" [ ]> d16 6 a21 2 The OpenPKG Handbook The definitive guide to OpenPKG for users and developers d25 5 a29 7 Ralf S. Engelschall d36 16 a51 9 OpenPKG (pronounced Open-Pee-Kay-Gi) is a self-contained cross-platform software packaging facility for Unix servers. It is currently available for Sun Solaris (SPARC), FreeBSD (iX86) and Debian GNU/Linux (iX86). The underlying packaging technology is based on an extended version of the popular RedHat Package Manager (RPM, v4) and supports both for source and binary packages. Currently already over 160 OpenPKG RPM packages are available. d54 4 a57 3 specifications (possible through the unique OpenPKG extensions to RPM) and are throughout buildable both as non-root and without write-access to the target installation hierarchy. d61 7 a67 5 OpenPKG is available as Open Source from http://www.openpkg.org/ and ftp://ftp.openpkg.org/ under the original licenses of the underlying third-party packages. All other unique OpenPKG parts are licensed under a BSD-style license. d73 4 a76 3 Munich, Germany. The OpenPKG project was founded in November 2000 and currently is (as of June 2001) in its deploying phase for customers. d81 2 d87 8 a94 8 This is the the first part containing the User's Guide to OpenPKG. It introduces OpenPKG from a user's point of view where "user" denotes the person who installs OpenPKG and OpenPKG RPM packages on a target machine. Persons who create OpenPKG RPM packages are denoted "developers" in our context. These can find their OpenPKG documentation in the part of this book, although they are entitled to also read this first part before, too. a144 16 The Platform d182 69 a250 1 user part, developer part d392 2 d400 3 a402 3 view where "developer" denotes the person who creates OpenPKG RPM packages. This part builds up on the first part of this book. @
The problem with the platforms... The problem with the plarforms...