pkg(5), the image packaging system (IPS), is an attempt to design and implement a software delivery system with interaction with a network repository as its primary design goal. Other key ideas are: safe execution for zones and other installation contexts, use of ZFS for efficiency and rollback, preventing the introduction of incorrect or incomplete packages, and efficient use of bandwidth.
We would really like to eliminate any bug you encounter—so every bug report we receive is valued. Should you run into a bug, please report them on the discussion list.
Our discussion alias is pkg-discuss AT ips.java.net. Ideas, issues, patches are all welcome; commit notifications add to the open development aura. The TODO list provides some potential areas to start; short essays and notes on various topics—such as content filtering, handling of ELF dependencies, and some initial RFEs]—can be found in the doc/ directory of the repository. More specific hints can be found in the [Developer Information Page].
$ pkg image-create -F -a opensolaris.org=http://pkg.opensolaris.org/dev/ /path/to/image
(If you're interested in developing pkg(5)-style packages, the best step at present is to join the discussion. As support for multiple package authors is fleshed out, we'll set up additional test publication spaces or repositories.)
The source code is stored in a Mercurial repository here at java.net. You can get a copy of the source tree via:
$ hg clone https://hg.java.net/hg/ips~pkg-gate
If you would like to browse the source directly, it's available via the java.net source browser:
Please get a contributor agreement in place before submitting anything but the most trivial of patches. At present, pkg(5) is being implemented in Python; we're developing in an ON-sympathetic coding style.
Current official documentation is available here. Also, you can read the draft manual pages directly out of the source code repository:
The one pager, which begins the architectural review, was recently published; the image packaging system will be tracked as case 2008/190.
The project team has been explaining some of the ingoing assumptions behind the project in a series of blog posts: