ObjectNecromancer - Alternatives

Among the community for Unix systems and clones, there exists a long tradition of providing free software packages in source code form. The only way to have Perl, XFree86, Heimdal or numerous other packages working many systems and architectures is to let anyone do the porting and compiling.

The job of a collection of software packages is to facilitate the porting, the compiling and the installing of multiple software packages. This page contrasts existing packages collections with Object Necromancer.

BSD

FreeBSD, NetBSD, OpenBSD, DragonFly, MirOS are all variants of 4.4BSD. Thus, they all provide a complete base system including the kernel, shell, system utilities, and gcc. Each BSD project employs a central CVS repository for development and maintenance, and employs the BSD variant of the Unix "make" command to build the base system. You can find the base system in the "src" module of the CVS repository.

The installation of other third-party packages, including the X Window System, is a separate matter. FreeBSD introduced the concept of a "ports collection". The FreeBSD Ports Collection automates the patching that is necessary to make some packages run above FreeBSD. The other ports collections claim the FreeBSD Ports Collection as ancestor.

The ports collections contain one Makefile per package. Each Makefile contains targets to automate the downloading, the patching, the building, and the installation of each package. The typical cd /usr/ports/games/nethack34/ && make install clean gives you NetHack and its dependencies!

NetBSD

NetBSD has three modules in CVS:

• "src" for the base system, except XFree86
• "xsrc" for XFree86 + customisations
• "pkgsrc" for third-party packages, including Xorg

Though pkgsrc is the official ports collection for NetBSD, the pkgsrc takes the stance that portability encourages correctness. Thus pkgsrc will install software onto several Unix clones, especially onto NetBSD and DragonFly, but also onto FreeBSD, OpenBSD, GNU/Linux, Solaris and others. From time to time, a look into the patches from pkgsrc may reveal how to edit the source code of a package into portable source code.

OpenBSD

OpenBSD has three modules in CVS:

• "src" for the base system
• "xenocara" for Xorg
• "ports" for the OpenBSD Ports Collection

The emphasis of the OpenBSD Ports Collection is to build official binary packages for the OpenBSD Packages Collection. Most users stay away from the Ports Collection and install software from the OpenBSD Packages Collection. This makes OpenBSD very convenient, because binary packages are easy to find. Kernigh often uses the official OpenBSD packages in conjunction with Object Necromancer.

MirPorts

In comparisons with Object Necromancer, MirPorts is most interesting. MirPorts is actually a fork of the OpenBSD Ports Collection that has retreated away from OpenBSD's goals. The home page of MirPorts does not say much, but the about page tells of "installing your own MirPorts instance as a non-root user". A PDF flyer also tells of efforts to move the dotfiles to ~/.etc, a goal that Object Necromancer now shares. MirPorts is also trying to support MirOS, OpenBSD, Mac OS X and Interix, though that puts its cross-platform features on a much smaller scale than pkgsrc.

GNU/Linux

GNU/Linux users have a special problem. The GNU/Linux system consists of numerous separate packages (bash, gcc, glibc, init, linux, ps, ...) with no central maintenance. GNU/Linux users need package systems for both the base system and third-party packages. The variety of package systems is what gave rise to the numerous different Linux distributions. In some sense, the collection of software packages is the distribution of GNU/Linux.

RPM Package Manager is a featureful tool employed by several distributions to supply binary packages. Users then use RPM to install the packages. Unfortunately, RPM packages tend to float around on their own (see rpmfind.net for example) instead of sticking to central repositories. Then they mix together and cause conflicts and incompatibilities.

Portage and Sorcery both emphasize that each user do their own builds of every package. The FreeBSD Ports Collection inspired Portage, but Portage uses shell script and Python instead of BSD make. Each Portage "ebuild" or Sorcery "spell" contains instructions to fetch the source code and build and install it. The two collections have their differences. Sorcery also is the reason that Kernigh does not refer to Object Necromancer as Source Necromancer!

However, all of these collections require the root user to perform the installation. There is no easy way for a user to install software into its home directory.

GAR

The developer designed GAR in a manner parallel to the FreeBSD Ports Collection, even using the same names for targets. However, GAR uses GNU make in lieu of BSD make. The original GAR built a small GNU/Linux distribution for business cards. GAR yells "GAR GAR GAR!" after an error.

Today GAR is mostly known as the technology behind GARNOME, which builds and installs the GNOME desktop into a user's home directory, and Konstruct, which does similar for KDE. Some users turn to GARNOME or Konstruct so that they may try or run a version of GNOME or KDE that is newer than the one from their GNU/Linux distribution. However, GAR has trouble with operating systems other than GNU/Linux.

GAR seemed to work okay upon OpenBSD until it tried to run a command, at which point if failed because it had exported LD_PRELOAD=, instructing ld.so, to load the nonexistant library.

JHBuild

Building modular X.org with jhbuild

JHBuild automates the building of several packages that belong to a "module set". There is at least a module set for GNOME (allowing JHBuild to be an alternative to GARNOME) and a module set for Xorg.

GAR and JHBuild already work today. Unlike Object Necromancer, GAR and JHBuild do know about dependencies.

You may edit this wiki page. The text is in the PublicDomain.