pkgjam will be a new way to build packages. We intend to radically re-engineer pkgsrc, keeping the best parts, dropping the worst, and creating new facilities to build and manage packages.
Important features of pkgjam:
All information about all packages, including any build options, are stored in a relational database. We have chosen at present to work use SQLite because:
ls(1)There are actually three databases:
bin describes installed packages. Of course, it starts out empty and is updated by the build/install tool. src describes all pkgsrc packages. It replaces the pkgsrc tree for purposes of building and installing packages.site captures any site-specific preferences. It replaces mk.conf. It also allows individual packages to be installed outside the normal /usr/pkg tree. This permits a given installation to take advantage of its pre-existing version of something ordinarily provided by pkgsrc.
The src database can be loaded from the existing pkgsrc tree using make show-vars VARIABLES="PKGNAME ...". The process takes hours even on a fast machine. (Queries against the database for the same information, on the other hand, are instantaneous.)
The build tool queries the database and creates an environment for the package to build in.
We anticipate a simpler pkgsrc tree. The basic tree will remain, but
the Makefile will be vastly simplified. Its whole job is reduced to providing targets that produce files suitable for importation into the database.
By moving package metadata to a relational store, it becomes a relatively simple matter — both quick and easy, if you know SQL — to answer such questions as:
/etc are used by packages?
For convenience, we should create a tool similar to pkg_info that answers the same questions (and more!) as it does today, but by querying the database instead of the filesystem.
When a package is built, it is installed in its own directory /usr/pkg/name, where name is the name & version of the package. Similarly its RPATH no longer points to /usr/pkg/lib. Instead, the RPATH is /usr/pkg/name/so, and all needed shared objects are hard-linked to that location.
By organizing applications this way, it becomes possible:
/etc). bin database from the installed files.
Proof of that statement, however, is left as an exercise to the reader.
The installed files are first installed in their pkgjam "islands":
/usr/pkg/jam/icewm/1.2.27/{bin,lib,etc,share}/usr/pkg/jam/Xaw3d/1.5/{bin,lib,etc,share}Then, because icewm uses Xaw3d, hard links to the shared objects are put there:
/usr/pkg/jam/icewm/1.2.27/soRPATH is /usr/pkg/jam/icewm/1.2.27/so.
The shell needs to be able to find installed executables. Several versions could be installed, and we don't want a PATH with a directory per package. When a package is installed, the last step is to put links to the executables (and documents, and config files) in POLA locations e.g.:
/usr/pkg/bin/usr/pkg/jam/icewm/1.2.27/bin.The documentation is similarly linked.
The new build tool replaces make(1) as the overall package management utility. It
src information with overrides in site)Makefile that depends on no particular version of make: all variable substitution, etc., is done inside the toolmake(1)bin databasesrc database is declarative; the maintainer (or builder, in site) says what options he wants and
the build system responds accordingly. The user gains flexibility with regard to installed libraries and keeping multiple versions of libraries and applications. Both parties benefit from well organinzed, easitly queried package metadata. ls(1)? /usr/pkg/bin at any time, and still be able to reinstall another version from the pkgjam "island" directory. ls -l is more informative than ls -i, neither is anywhere near as complete as the pkgjam database. src database (the one that describes how to build packages), you just download another. bin database (that describes installed packages), most of the important information — notably dependencies — can be recovered from the directory structure. site database (that describes your site preferences), you'll have to consult your backups. It's very small, and can be quickly dumped out as plain text. src database is the handiwork of James K. Lowden, so you can blame him.