OpenSolaris

1. Project: Image Packaging System
   1. News
   2. Developer information
   3. Blogs
   4. Discussions
   5. Observers
   6. Leaders
   7. Documentation
      1. Getting Started with IPS
   8. Adding Packages to IPS

Info for developers

Common issues

• Using localhost as a repository doesn't mix well with http_proxy environment settings. Your proxy will probably get confused about who you meant by localhost. There's code to handle this case on a few paths, but not all paths. For now, turn off your proxy setting before invoking the pkg commands.
• I don't know Python--how best to learn? The current developers are all relatively new to Python, but are old hands at C/Make/shell and so on. For programmers already familiar with Unix programming, Stephen recommends David Beazley's Python Essential Reference (3rd Edition). Danek has had as much success just using online resources, such as docs.python.org. (The bundled Python we're using is presently 2.4.4.)
• The elf module won't compile. The current targets assume that you have the DevPro cc C compiler in your path. If you don't, you'll see something like

  $ make install
  cp client.py pkg
  cp publish.py pkgsend
  cp depot.py pkg.depotd
  /home/sch/projects/pkg/repo/pkg-inc-1/src/modules
  cc -c -Kpic -I/usr/include/python2.4 arch.c
  sh: cc: not found
  *** Error code 1
  make: Fatal error: Command failed for target `arch.o'
  Current working directory /home/sch/projects/pkg/repo/pkg-inc-1/src/modules
  *** Error code 1
  The following command caused the error:
  cd modules; pwd; make all
  make: Fatal error: Command failed for target `binary-modules'
  

  There's a workaround (until we get a Makefile patch): cd modules; make gcc will build the elf module using gcc, if it's on your path.

Running a development server, smf(5)-style

One convenient way to run the server is, after pulling down a child, is to use the link Makefile target to connect your repository's bits into the system. That is,

$ cd path/to/child
$ cd src
$ su
Password:
# make link
# svccfg import pkg-server.xml

Then, anytime you want to reload the server (because you edited module source, say), you only have to issue

# ./bump-server.ksh

(You can do this as non-root, if you've given yourself the "Service Management" profile in /etc/user_attr.)

Running the client and server from the workspace proto area

Developers may find it easier to run the client and server from their location in the workspace proto area.

Server

$ WS=<path to root of workspace>
$ PYTHONPATH=$WS/proto/root_`uname -p`/usr/lib/python2.4/vendor-packages/; export PYTHONPATH
$ PKG_REPO=<path to repo> $WS/proto/root_`uname -p`/usr/lib/pkg.depotd

Client

$ WS=<path to workspace root>
$ PYTHONPATH=$WS/proto/root_`uname -p`/usr/lib/python2.4/vendor-packages/; export PYTHONPATH
$ PATH=$WS/proto/root_`uname -p`/usr/bin:$PATH; export PATH
$ PKG_IMAGE=<path to image root>; export PKG_IMAGE
$ pkg image-create -F -a authname=http://<server address>:10000 $PKG_IMAGE
$ pkg refresh
$ pkg install <package>

Bug Management

Bugs should be filed on defect.opensolaris.org, under classification "Development", product "pkg".

When you grab a bug to work on it, please assign yourself to the bug. If you decide to stop working on it, reset the assignee to the default.

Although bugzilla should constrain the state transition to some extent, if we constrain it too much, you have to go through a number of state transitions to get to where you want to go. If there are problems with the state transitions (like they're proving to be super inconvenient), raise the issue on pkg-discuss.

Generally, when you figure out why the buggy behavior is as it is, explain it and change the state to CAUSEKNOWN. When you figure out how to fix it, explain the fix and change the state to FIXUNDERSTOOD. When you actually start fixing the bug, change the state to FIXINPROGRESS. Once you've gotten all your testing done, reviews completed, etc, and pushed a changeset containing the fix to the main repository, add a comment like "Fixed in changeset ." (where is either the short or long hex changeset id), and change the state to FIXINSOURCE.

Unless you're a project leader, don't change the state to anything more resolved than that, unless you're closing it off as a duplicate, saying you won't fix it, or can't reproduce, etc. Don't mark it as RESOLVED/FIXED or CLOSED/FIXED or FIXINBUILD. These are all "gatekeeper" states, at least for now.