Package Once, Use Everywhere
Cross-platform Unix software packaging with OpenPKG
You might prefer Open Source software for its well-known advantages, but
sometimes regret the downside of its associated open and distributed
development when trying to apply it manually to your work environment.
To keep a work environment stable and secure, it's often necessary to
locate the latest version of an application on the Internet and collect
its most recent patches containing security and bug fixes. However,
there is often no single location for these files. After the search
finishes, a system administrator must build and install the new binaries
on every Unix box in the network, and might find that the application
needs slight tweaking on each of them.
Then after a round of laborious build manipulation, it might not be
clear that the application will run as intended on each of the different
platforms. If the application is a daemon even more work awaits, because
most Unix flavors have their own method of starting and stopping
daemons.
If the previous operation succeeds after all, the system administrator
might be left to wonder why it is necessary to clutter up the system
with residual installation files and how do the vendors think the
residue should be removed? Also, if the /var file system later runs
out of disk space due to an overgrown application log, do the vendors
think that the responsibility lies with the system administrator to
implement log file rotation himself? Such redundant basic tasks can and
should be avoided.
What can a system administrator do when facing obstacles like these?
He might start by sticking with vendor packages only. Unfortunately,
there may be several different Unix variants to administer. Worse yet,
no existing vendor packaging facility supports multiple installation of
an application, a feature useful for multiple project coexistence on a
single machine and independent package testing. Another missing feature
regards the management of coexisting packaged and unpackaged software.
Finally, if the system administrator wants a software installation and
configuration guide for his vacation replacement, he might as well give
up. This is usually impossible, because every vendor packaging approach
is different and cannot be uniformly applied across all major Unix
platforms.
OpenPKG to the rescue
OpenPKG is a large Open Source software packaging project.
The project began in November 2000, and has grown to be a collaborative
software development effort managed and maintained by many. The project
aims to create a modular and flexible Unix subsystem for cross-platform
software packaging and installation.
More specifically, the goals of OpenPKG stem from the historical problem
often faced in the daily operation of a datacenter environment. The
major Unix platforms in operation in datacenters include FreeBSD, Linux
and Solaris. To satisfy the demands of such a diverse Unix computing
environment, the installation and maintenance of software packages
across these platforms greatly benefits from a unified and consistent
approach.
OpenPKG is not limited to the three major platforms just mentioned,
however. OpenPKG has more ambitious goals and runs on most major Unix
platforms. To achieve such cross-platform portability, OpenPKG provides
a subsystem on top of the underlying Unix system as shown in Figure 1.
It covers every essential server software component from shells,
editors, compilers, and up to network daemons and add-on applications.
Hence, the intended target community consists of system administrators
faced with a large and diverse set of Unix servers.
Internally, OpenPKG leverages the existing packaging technology of
the popular RedHat Package Manager (RPM). However, the RPM software
included with OpenPKG is specially extended to become more unique and
self-contained. The nearly 1000 available OpenPKG packages are really
just RPM packages under the hood, but were developed from scratch in an
OpenPKG standard approach. The packages are clean and robust, because
they follow extremely strict style guidelines and environment requirements.
To meet these OpenPKG guidelines and standards, a package must be built
from pristine vendor sources in a non-privileged temporary environment.
It has to work under an arbitrary file system location, has to follow a
strict file system layout, and must be fully self-contained within its
OpenPKG instance. Furthermore, the package must be maximum independent
from external Unix facilities, has to install with a reasonable and
ready to go configuration, and has to use log file rotations and other
such administrative wonders.
These well specified package-building guidelines yield several benefits
to OpenPKG users. OpenPKG users can install an instance (the OpenPKG
subsystem and user-chosen packages) under any file system location,
and even install multiple such instances on a single Unix system.
Incidentally, the main OpenPKG project environment is hosted on a
machine with fourteen other ongoing software projects, each with their
own dedicated OpenPKG instance. To separately satisfy each project's
needs, the associated OpenPKG instance serves every required software
component from Postfix to BIND, and INN to Apache. Each project can
therefore run in its own isolated environment, much like on a virtual
machine — but without any virtualization overhead.
Covering the whole OpenPKG package lifecycle
OpenPKG follows an approach of minimum OS intrusion and maximum
standalone presence. It tries hard to smooth out the differences between
the underlying vendor solutions. Sometimes this means that it has to
break with well known standards in order to provide a cleaner solution.
This is the most reasonable approach, and leads to a consistent
cross-platform solution.
A question often asked is, "why does OpenPKG use RPM as the underlying
packaging technology when other alternatives exist?" There are indeed
other similar packaging technologies available to projects like
OpenPKG, with the most prominent alternatives to RPM being the Debian
dpkg/apt combination, FreeBSD ports, and System V pkgadd.
According to some, RPM may not be the greatest packaging system since
sliced bread. However, RPM along with its OpenPKG extensions is the only
solution covering the whole package lifecycle in a fully consistent
way.
To elaborate, the OpenPKG package lifecycle starts with automated
tracking, fetching, unpacking, patching, and building the source package
from pristine vendor sources. It goes on to build the binary package
in an unprivileged environment, and finishes its life term with the
installation, upgrade, and uninstallation of the binary package on the
target OpenPKG instance. This all works in a self-contained environment,
and is driven by concise yet complete package specifications (RPM
.spec files). So, to finally answer the question, OpenPKG adopts RPM
as its underlying packaging technology because no other can fulfill
these steep requirements.
It is important to note that OpenPKG is primarily about packaging,
not porting. A requirement of the OpenPKG packaging philosophy is
that the vendor software has to be inherently portable to begin with.
Minor platform porting issues are fixed by the OpenPKG packagers, but
fundamental changes are not considered. In fact, the main reason for
some platforms lacking full OpenPKG support is that the amount of
overhead in building software on them is not within reason.
It may surprise some that OpenPKG officially discourages the use of
binary packages, and only provides them for bootstrapping (development
tools not available) and emergency (tight time constraints) purposes.
Experience has shown that installing binary packages built from source
packages on the target machine outperforms other binary methods in
respect to security and robustness.
There are simply too many subtle differences between most build and
install systems that can influence the binary at run time and cause
trouble. Some important run time parameters, such as the maximum size
of shared memory segments, are compiled into the binary on the build
machine. Among many examples of such a run time build dependency is
a situation in which an Apache package is built with mod_ssl and OSSP mm.
The dependency details of such a combination are overwhelming, when
sorting out the run time parameters. To avoid such trouble, OpenPKG
believes that the only reasonable solution is to always start with
source packages.
Bootstrapping OpenPKG for the first time
The OpenPKG bootstrapping process is wrapped into a tricky shell script
that when run, will create a new instance of OpenPKG. This process is as
self-contained as possible, and requires a minimum amount of operating
system support and tools to unpack and compile itself. In the best case,
the script will search the $PATH for the development tools tar,
make and cc and use them in its processing. If any of these tools
are missing, an alternative approach exists in which a shell script
containing binaries provides the missing tools. FIXME?
The first step in bootstrapping involves dedicating a unique
file system prefix to the instance along with user and
group ids. The generic bootstrap building script called
openpkg-version-release.src.sh requires these arguments
and creates a platform specific bootstrap installation script named
openpkg-version-release.arch-os-tag.sh.
When run, this script installs the OpenPKG instance under the specified
prefix with all files owned by the user and group (Figure 2).
This bootstrapping process links the OpenPKG instance with the
underlying Unix system in a very mild way with only a few anchor points.
Subsequent package installations do not touch the system at all, and if
OpenPKG itself is uninstalled, the anchor points vanish.
After creating a self-contained hierarchy the bootstrap process
registers itself as the openpkg package, and can thus be upgraded
or treated just like any other package. To make upgrade an already
bootstrapped OpenPKG instance easier, .rpm versions of the bootstrap
package are available as well.
A step by step example of a complete installation and uninstallation of
an OpenPKG instance with a RSYNC server package is given in Listing 4.
To understand the OpenPKG RPM commands used, see the quick reference in
Table 2.
OpenPKG file system layout
Every file system standard sucks. OpenPKG's file system aims to suck
less (Figure 2). Basically, its package area resembles the traditional
layout found under /usr on most popular Unix systems. Additionally,
it contains its own OpenPKG RPM package management information in a sub-area for
purposes of self-containment plus a local area for adding unpackaged
components.
OpenPKG does break with tradition in one aspect of its file system
layout, however. It unconventionally uses a separate subdirectory of
prefix/etc/, prefix/share/ and prefix/var/ for each
installed package. These subdirectories are easy to manage, because
each is named after its associated package. This provides for a better
structure than the usual mess of files, and every OpenPKG package
adheres to this layout scheme (even when requiring a lot of effort to
override the different vendor package intentions).
Looking again at the RSYNC example in Listing 4, you can conclude right
away that the RSYNC configuration is in prefix/etc/rsync/, and it
logs to somewhere in prefix/var/rsync/. Such ease of maintenance
makes backups easier, moving whole instances without hassle, and more.
Managing OpenPKG packages
When building packages, the temporary files are placed into
subdirectories of prefix/RPM/ by default. A package builder can
obtain the necessary subdirectory access by either being a member of
the associated OpenPKG group, logging in under the management user
id of the OpenPKG instance, or logging in as root. A carefully
written ~/.rpmmacros file can alternatively redirect the paths to a
specified location (see the default macros %_sourcedir, %_specdir,
%_builddir, %_tmppath, %_rpmdir, %_srcrpmdir in
prefix/etc/openpkg/rpmmacros) and this way allow even an arbitrary
user to build packages.
To build a binary package pkg-bin from a source package pkg-src,
use openpkg rpm --rebuild pkg-src. OpenPKG RPM will read the
.spec information of the pkg-src, build the package based
on the information, and place the resulting binary package in
prefix/RPM/PKG/pkg-bin.
To finally install the binary package so that it becomes part of the
OpenPKG instance, just use openpkg rpm -Uvh pkg-bin. Strictly
speaking this upgrades the package. To OpenPKG RPM, installation is
nothing more than the special case of upgrading from nothing.
As a side note, some packages provide alternative build variants through
boolean variables named with_name. To determine which variables
are available (if any at all), run "openpkg rpm -qpi pkg-src | grep
with_". To build a binary package using such variables, add --with name
or --withoutname to the openpkg rpm --rebuild command to
override the default value.
OpenPKG RPM is very clever when it comes to keeping configuration files
during an upgrade, as shown in Table 1. An old configuration file
is kept if the system administrator stuck to default configuration
which remained the same, or if the configuration was changed but
coincidentally matches the default configuration of the new package. In
practice, a administrator-changed configuration must be reapplied in few
cases of package upgrade.
In any case, should a configuration file not be kept, OpenPKG RPM saves the
old configuration file with the extension .rpmsave before saving
a new default in its place. This ensures that changes to a default
configuration can be recovered and reapplied so that an upgraded package
runs correctly. Should a new default configuration file replace an old
one that retains its original (but old) default, OpenPKG RPM will rename it
with the extension .rpmorig.
To make this delightful mechanism work properly, the configuration files
of each package have to be explicitly tagged. OpenPKG packages all
follow this principle, which further contributes to OpenPKG's robust
nature. OpenPKG RPM does the intuitive right thing by making sure that
a changed configuration file is kept in place if possible and if not,
then preserves it for manual consideration and application.
Finally, after the installation of a package, you can query a lot
of its information. The command openpkg rpm -qi pkg-name
summarizes a single installed package, while openpkg rpm -qa lists
the names of all installed packages. openpkg rpm -qlv pkg-name
lists all the files associated with a package and openpkg rpm -qf
prefix/path/to/file reveals to which package the given file
belongs. You can even check a package's integrity using openpkg rpm -V
pkg-name to verify which files have been tampered with or somehow
munged. For more details on this refer to Table 2.
The OpenPKG run-command facility
You might have noticed that in the previous example installation of
RSYNC, the server was started using the command openpkg rc rsync
start. The workhorse behind this simple statement is the powerful
OpenPKG run-command facility. Run-commands for every package are
conveniently named prefix/etc/rc.d/rc.pkg-name. What each
of them offers is the functionality of several shell script segments
encapsulated in a single file. The sections of a run-command file are
identified by left-aligned labels prefixed with '%'. Listing 2 shows
rc.rsync as an example.
The openpkg rc command takes pkg-name as the first argument and one or
more section labels as additional arguments. The run command segments
corresponding with the desired section labels are then extracted from
the rc.pkg-name file and executed in the order given on the
command line. The reserved package name all serves as a wildcard and
refers to all installed OpenPKG packages, causing the processing of all
run-command files in a specified order. In this case, the run-command
facility will order the run-command processing according to the priority
field (-p number) of the given section label in each run-command
file. Another popular field in a section label is -u user, which
directs the script code to execute with the privileges of user.
Most sections in a run-command file have arbitrary labels intended to
be used as command line arguments to the run-command facility. However,
some sections have special meaning. The section labels of these are
reserved names used internally by the run-command facility. For example,
the %common section functions as a library and contains script code
useful to some or all of the other sections. Its script code is run
before any other script code.
Just like its cousin, the %common section, the %config section
can appear only one time in each run-command file. It contains
variables used to configure the behavior of the other sections
residing in the same run-command file. This means that the logging
and enabling variables in a %config section will only affect the
associated package, for example. Such variables can be overridden in
prefix/etc/rc.conf in a per-hierarchy scope, however. Technically,
the run-command facility assembles a large script file from the
%config section, the prefix/etc/rc.conf file, the %common
section, and finally the user-defined section given as an argument (in
that order). The fat script it then executed.
The sections %monthly, %weekly, %daily, %hourly and
%quarterly also have special meaning, as the OpenPKG bootstrap
process sets up cron jobs to execute them accordingly. Another label
often seen is %env, which is intended to be used with the --eval
option explained below.
| |
Regarding configuration through variables, it should be mentioned
that the rc.pkg-name file is intentionally not tagged as a
configuration file and will be overwritten on updates with no questions
asked. The prefix/etc/rc.conf file is tagged as a configuration
file and is intended for overriding variables.
With OpenPKG, all daemon packages are released with scripts that
recognize the value of a variable pkg-name_enable (default value
"yes"). Setting this variable to "no" disables all run-commands of
the daemon in question. As seen with the RSYNC server example, this can
be quite useful when installing a package just to get a client piece.
Should the server piece not be of interest, then a simple variable
shuts it off completely. Similarly, to disable the automatic startup
of all daemons in a hierarchy, just add a openpkg_rc_all="no" to
prefix/etc/rc.conf. In this case, daemons can still be started
manually. This feature may be of interest to system administrators
wanting control over daemons with finer granularity.
The OpenPKG run-command facility has many other interesting features.
Use openpkg rc --query variable to see the effective value of any
configured variable, or use openpkg rc --config to see a complete list of
all available variables with their default and effective values. Last
but not least the run-command facility offers a very handy feature to
allow packages to extend the user shell environment. For instance the
bootstrap package openpkg uses this to add the OpenPKG instance
into your PATH, MANPATH, INFOPATH, etc. Just execute eval
`prefix/bin/openpkg rc --eval openpkg env` to perform this
environment extension for your current shell session.
OpenPKG RPM vs. RedHat RPM
As mentioned, OpenPKG is based on a uniquely adjusted and extended
RPM-based packaging facility which allows for very concise and
clean package specifications and building of every package in
an unprivileged environment. Is this any different than what the
RedHat, SuSE, or Mandrake implementations offer? To understand the
added value of the OpenPKG implementation, let's take as example the
OpenPKG packaging of the RSYNC program. The OpenPKG packaging consists
of three files: the OpenPKG RPM specification (rsync.spec, Listing 1),
the run-commands (rc.rsync, Listing 2), and the default daemon
configuration (rsync.conf, Listing 3). In comparison with the
RPM-based RSYNC package of other vendors, the OpenPKG RPM-based package
is full featured yet very concise and clean. This is due to the use of
OpenPKG RPM extensions and strict style guidelines.
To offer more portable and concise shell scripting, OpenPKG RPM uses GNU
shtool. All manual installation and patching is done with the shtool
command. A companion tool, rpmtool, complements shtool with
OpenPKG RPM and OS-specific features. The rpmtool allows all OpenPKG
packages to generate their file list (%files) on the fly and makes
the packaging information smaller. It reduces the required maintenance
when vendor version updates occur as well.
OpenPKG RPM additionally provides a set of local macros (%{l_xxx})
to abstract system specifics and also help in removing redundancy from
packaging specifications. For example, the %{l_prefix} is the file
system prefix of the associated OpenPKG instance. Using OpenPKG's
local macros offers a clear advantage, because packages no longer need
hard-coded path prefixes and can therefore be built for arbitrary
OpenPKG instances.
Macros exist for the most often used build variables. The %{l_cc}
macro expands to either prefix/bin/cc (in case the OpenPKG gcc
package is installed) or defaults to just cc. The same goes for
"%{l_cflags -O}": it expands to the optimized C compiler flags. In
case gcc is installed, it expands to "-O2 -pipe". Otherwise,
it expands to just "-O" by default. The variables %{l_make} and
%{l_mflags} work together in a similar way. If %{l_make} points
to a known make which supports parallel building and the underlying
system has more than one CPU, then "%{l_mflags -O}" expands to the
necessary flags to leverage the system's multiple processing power. For
example, on a 2 CPU FreeBSD machine with BSD make, "%{l_mflags
-O}" expands to "-j4 -B" while on a 4 CPU Linux machine with GNU make,
"%{l_mflags -O}" expands to "--no-print-directory -j8".
Many packages also deploy a tricky OpenPKG-specific package build
option feature based on OpenPKG RPM's %define macro and the Provides
header: A package specification foo.spec can contain zero or more
"%option opt-name opt-default-value" lines which expand to both
a "%ifndef opt-name %define opt-name opt-default-value
%endif" construct and a "Provides: foo::opt-name =
opt-value" header definition. First, this allows the package itself
to conditionally build with variations through the use of following
'%if "%{opt-name}" == "opt-value" … %endif'
constructs inside the foo.spec file.
The compared effective option value is either opt-default-value
or the opt-override-value from a "--define 'opt-name
opt-override-value'" or "--with opt-name" or or "--without
opt-name" command line options. Second, the resulting source RPM
can be queried with "openpkg rpm -qp --provides" or "rpm -qpi" in order
to lookup the provided options and their default values. The same can
be done for the binary RPM to lookup the options and their effective
values which were used to built the package. Third, another package
depending on foo usually just uses "[Build]PreReq: … foo".
In OpenPKG it also can depend on a particular build variation of foo
by using "[Build]PreReq: … foo, foo::opt-name =
opt-value". The consequent of this functionality provides both a
clean, precise and flexible packaging.
Additionally, all OpenPKG packages follow exactly the same style
as the RSYNC example (see Listing 1, Listing 2, and Listing 3). The
header order, indentation, etc. is fully standardized, and allows developers
to easily query and even semi-automatically edit package information
directly from the source. Incidentally, the indices on the OpenPKG FTP
server and the OpenPKG release engineering procedures are auto generated
by exploiting this standard scheme.
Every OpenPKG package is able to build in an unprivileged (non-root
user) environment and with read-only access to an OpenPKG instance.
This allows safe (no development system intrusion) and precise (no
trashed or missing files) packaging. Such security and precision
is achieved by consistently using the BuildRoot feature of RPM
for all packages. In short, this means that when rolling a binary
package the software is redirected to install into a shadow area
(prefix/RPM/TMP/pkg-name-root/prefix). The package is
then made from the shadow area just as if it were located in the real
file system location (prefix). This important improvement to the
standard RPM behavior may sound trivial and easy to achieve, but is
actually one of the trickiest steps in packaging software for OpenPKG.
Sometimes (as with RSYNC), it is just a matter of overriding variables
(prefix in the example) on the "make install" step. Other times the
solution is more involved. For some OpenPKG packages it takes a lot of
effort to find a reasonable way to redirect the vendor installation to
the BuildRoot location, but the extra effort is always worthwhile and
results in safer and more precise packaging.
Finally, OpenPKG's RPM implementation provides proxy packages, a tricky
and appealing mechanism for reusing the packages of a master OpenPKG
instance. Proxy packages can reside in multiple slave OpenPKG instances,
and allow the system administrator to avoid redundant building and
maintaining of the same software package in multiple OpenPKG instances.
For example, gcc is typically required by many packages at build
time. A gcc OpenPKG package is usually needed in every OpenPKG
instance.
A savvy system administrator will install a single gcc package
in a master OpenPKG instance and then only proxy packages (pointing
to the real gcc) in the other OpenPKG instances by running
slave-prefix/bin/openpkg makeproxy on the gcc binary RPM of
the master instance. OpenPKG's RPM will then produce a binary RPM
package for the slace instance, containing a shadow tree resembling the
contents of the master instance. The shadow tree is technically nothing
more than symbolic links to the master (non-proxy) package's files
and directories. This mechanism can save a lot of time and storage,
however it should only be applied to packages with global configuration
dependencies only or with no configuration dependencies at all.
Integrating unpackaged software
No matter how many packages OpenPKG provides, the world will always have
appealing yet unpackaged software. Ambitious system administrators can
package the software themselves for local purposes and even contribute
such new packages to the OpenPKG community. Alternatively, the local
subdirectory of an OpenPKG instance exists for the purpose of containing
unpackaged software, and can be instrumental in integrating a base of
OpenPKG packages with other unpackaged software in an easy to maintain
way. OpenPKG also provides a corresponding lsync tool to aid such
integration.
To integrate unpackaged software into an OpenPKG instance, each
unpackaged software component may be installed into the bin,
sbin, man, info, include and lib subdirectories of
prefix/local/PKG/pkg-name/ and then virtually linked into
the corresponding top-level directories under prefix/local/ by
running prefix/bin/openpkg lsync. This easy to administer strategy
leads to a very clean and maintainable OpenPKG instance, even with
its new coexisting unpackaged software in prefix/local/.
This especially makes it easy to uninstall a package. Just remove
prefix/local/PKG/pkg-name/ with all its contents and run
openpkg lsync again.
This strategy even allows for installation of different
versions of the same software. Just install into
prefix/local/PKG/pkg-name-version/ and add a symbolic
link pointing from prefix/local/PKG/pkg-name/ to this
directory. This works, because openpkg lsync skips subdirectories of
prefix/local/PKG/ with version numbers attached. To upgrade an
older foo-0.7.41 to foo-0.7.42, just repeat the installation in
the same way, altering the symlink prefix/local/PKG/foo to point
to foo-0.7.42 instead and running openpkg lsync again. openpkg
lsync will automatically update symlinks, creating new links if
required and removing outdated dangling ones. As might be guessed, it is
just as easy to go back to the old version if the new one keeps dumping
core or something like that. For an example of such multiple unpackaged
software installation see Figure 3.
OpenPKG release engineering
A carefully crafted release process is part of the OpenPKG project, and
the fruits of the whole project are available to the public according
to Open Source standards. All sources (package specifications, source
patches, website sources, the handbook, this article, etc) are located
in a publicly readable central CVS repository, which can be browsed
anonymously by conventional cvs commands or through the website
for added convenience. Additionally, all developer commits to this
repository are tracked and summarized with postings to public mailing
lists and public newsgroups. People can easily follow all developments
by subscribing to the list or reading the newsgroup.
For stability and to reduce conflicts between development milestones,
OpenPKG has three release branches (which technically directly
map to CVS branches.) These are OpenPKG-SOLID, OpenPKG-STABLE and
OpenPKG-CURRENT. OpenPKG-SOLID is the security update branch of the last
public OpenPKG release. OpenPKG-STABLE is the stable branch from whose
contents the next public release is made. OpenPKG-CURRENT is the current
state of the development branch, and contains packages of beta-grade
stability.
In any case, the branch from which a package was built can easily
be determined by the OpenPKG RPM file name, because they follow a
consistent naming scheme: pkg-name-version-YYYYMMDD
(for CURRENT), pkg-name-version-N.YYYYMMDD (for
N-STABLE), pkg-name-version-N.M.X (for
N.M.X-SOLID). Once such a source OpenPKG RPM package is built, the
new binary OpenPKG RPM package filename contains even more information,
such as operating system, hardware, and the OpenPKG instance tag.
The OpenPKG developer team is extremely very fast in keeping
OpenPKG-CURRENT packages up to date and in sync with the latest upstream
vendor versions. This is due to the fact that the versions of all
externally available vendor sources are fully automatically tracked on a
bi-daily basis. An OpenPKG package for a new vendor software version is
often available before the software is even announced on Freshmeat.net.
Finally, OpenPKG takes security very seriously. Experience has shown
that "security through obscurity" does not work, and that public
disclosure leads to quicker and better solutions to security problems.
In that vein, OpenPKG tries to release fixed packages as fast as
possible after a vulnerability was discovered. The OpenPKG security
release and advisory process notifies the community by publishing
official security advisories in the security section of the website and
on the mailing lists.
Conclusion
OpenPKG is an Open Source software project existing
since November 2000. The implementation relies on RPM 4 for
its basic packaging mechanism, but offers more than RPM alone. To
meet its goal of becoming a modular and flexible Unix subsystem for
cross-platform software packaging and installation, OpenPKG includes
tricky bootstrapping logic that installs a customized implementation of
RPM 4 on any of the supported target platforms.
OpenPKG is in production use since April 2001 in datacenter
environments of large ISPs. Since its public release in January 2002,
OpenPKG users have profited from an increase from 220 to nearly 1000 software
packages. The project is continuously improved by a diverse team of
developers who also daily update and add packages.
The base of OpenPKG software packages is expected to increase even more,
partly due to the ease of writing specifications and building packages.
Most OpenPKG users find it deceivingly simple to build a basic package.
New users interested in such packaging can use the RSYNC example in this
article as a blueprint. Accordingly, package contributions are always
appreciated by the members of the OpenPKG project and the members
of the OpenPKG Foundation.
References
OpenPKG:
http://www.openpkg.org/
ftp://ftp.openpkg.org/
OpenPKG Community Forums:
mailto:openpkg-users@openpkg.org
mailto:openpkg-dev@openpkg.org
nntp://news.openpkg.org/openpkg.users
nntp://news.openpkg.org/openpkg.dev
About the authors
Ralf S. Engelschall is a computer scientist and Open Source software
hacker. He is the author of well-known software like Apache mod_ssl,
GNU Pth, and GNU Shtool and the founder of Open Source software
projects like OpenSSL, OpenPKG, and OSSP.
He can be contacted at: rse@engelschall.com
Thomas Lotterer is a network professional and consultant working as a
Unix software developer. He gained experience in cross-platform system
integration and software distribution by working previously as a system
administrator and technical trainer. Today, Thomas works actively on the
OpenPKG and OSSP projects.
He can be contacted at: thomas@lotterer.net
Christoph Schug is a senior Unix system administrator. His revolutionary
ideas and visions often result in additional lines in Ralf's TODO list.
When not in the office, Christoph might be found in the Alps steering
the screaming and smoking tires of his Miata MX-5 roadster.
He can be contacted at: chris@schug.net
Michael Schloh von Bennewitz is a software engineer. He was an active
contributor to both the OpenPKG and OSSP projects.
He can be contacted at: michael@schloh.com
(Last Modified: 2006-09-26)
|
