Mpak is being designed from the ground up to be a kernel and
architecture independent package manager for free operating
- a single statically linked executable: The package manager
is responsible for installing all packages, including packages like
glibc, which the whole system depends on. In the event that a critical
package is damaged, we should be able to use the package manager to
install a replacement for the package, so other system functionality
can be repaired. To install a new operating system, a user will only
need a boot CD (or an already running system) and a copy of the mpak
- dependency tracking: Mpak will be able to find and install
all the dependencies for a package. Dependency cycles will be
automatically handled via a bootstrapping mechanism.
- the package tree: Package metadata will be kept in a
directory tree, organized by category. An installation of an mpak
based distribution will have a "system" tree. There will be
support for external trees provided by other vendors. Developers may
provide package trees for their own projects.
- support for building from source and binary packages: Mpak
will be able to use binary packages and build packages automatically
- optional feature support: Many packages have optional
build-time features. Mpak will have support for these. Following
autoconf's lead, we will divide them into supported packages
(e.g. --with-gnome) and internal features
- kernel and architecture indepence: mpak will have features
to simplify porting to different kernels. This way, we can have a
unified distribution with support for many kernels (Linux, Hurd, BSD,
Darwin, etc.), with nearly identical functionality across kernels.
- package binding support: mpak will be able to bind an
installation of a package to another installed package. For example,
suppose you have 2 versions of the linux kernel installed, 2.4.19 and
2.4.20. You want to install the alsa-drivers package for both of these
kernels. Normally, you would only be able to install one copy of
alsa-drivers, but mpak will let you bind the package to the linux
kernel package, so that you can have one installation of alsa-drivers
for each version of the linux kernel package you have installed.
- hard and soft dependencies: mpak will have support for hard
and soft dependencies. Suppose package A has a hard dependency on
package B. Then, when package B is upgraded, package A will need to be
rebuilt. If package A had a soft dependency on package B, then A would
not need to be rebuilt.