Making a Packman Package

/!\ Packman is obsolete, please contribute pkgsrc packages only (see Testing Pkgsrc)

We actively encourage people to write and port software to MINIX 3. MINIX 3 packages have a standard format that is required by the easypack package-manager. Here are the easy rules. Please stick to them, as they will make it easier for us to process your software, and easier for other people to install it the first time with no glitches.

1. Every package must have a unique name; for example, “foo-1.2.4”, where the part before the hyphen is the program name, and the part after it is the version number. Together, they form the package name.

1. The top directory of your source package must contain an executable shell-script called “build.minix” that builds and installs the package. For example:

  #!/bin/sh
  make
  make install

That script will be called by:

• binpackage, which builds binary packages from source-files.
• easypack, which downloads source packages, and builds programs from them.

All invocations will be done using the -e option to sh, so that failed commands will abort the script. For some packages, you might need additional (configuration) commands; but, in most cases, the package must be built correctly and installed by just typing “sh build.minix” (however, see below, about .postinstall). Easypack relies on that behavior (older versions used just “build”; so, you might need to edit your version of easypack to try both names). The “build.minix” script should exit normally if the package was installed correctly, and exit with an error-code otherwise.

1. Don't touch any files, in the system outside of your build tree, that don't relate to your package (e.g., calling chmem or makewhatis is a no-no). The binpackage script will think that it's a part of your package, and will include that file.

1. The entire build procedure should not rely on files having a particular mode (such as being executable). For example, do not use ./configure in “build.minix”; use sh -e configure instead.

1. Set the PREFIX to “/usr/local”; but, see the next rule, about libraries.

1. Libraries should go into “/usr/local/lib/ack” or “/usr/local/lib/gcc” or both, depending on which compiler and linker are used.

1. To compile C programs, you can use either cc or gcc, although we prefer cc where possible. The two compilers issue quite different warnings; and usually, both of them are right. For C++ programs, use g++, available from the Minix web-site.

1. The command make install should use the install program to copy your program to “/usr/local/bin”. That method will work even when the user is logged in as bin (not root!).

1. Every program must have a man page, in the standard format. The make install command should install man pages into the appropriate subdirectories of “/usr/local/man”. Most man pages that are about programs go into “/usr/local/man/man1”; but, extended user-guides go into “/usr/local/man/man9”.

1. Make your “build.minix” script so that, if it is run again, it installs everything all over again. Not only will that help greatly after a failed build, but our mechanism for generating binary packages relies on that happening.

1. Do not submit your source package with any generated files, such as object files, or generated Makefiles. Make your build-fixes to already existing files, and by including options or by setting environment variables in the “build.minix” script. Adding new files is OK.

1. PostInstall(This will become a rule about the optional “.postinstall” script.)

1. Add a “.descr” file to the root of the package, with a short (up to 50 characters) one-line description.

1. Similarly, add a list of build dependencies (“.bdeps”) and runtime dependencies (“.rdeps”) for this package, both in the form of a plain-text list of package names (including version numbers), one per line.

1. You can test if your source package successfully makes a good binary package by running

  binpackage yourpackagedir packagesdir

Binpackage will run your build script; and after that, it will scan your entire file-system (minus some directories which are not expected to contain new package files, but are expected to have files changed) looking for updates, which then are expected to be parts of the installed package. The resulting package ends up in “packagesdir/yourpackagedir.tar.bz2”. That is why your build script shouldn't “touch” any files outside of your package.

After thorough testing, please put your package on the “New Packages” tracker, by creating a new tracker item there. Rather than uploading a huge file, you are kindly requested to submit your package in the form of these two items:

• A link to the original, unmodified source of the software that you used for your port.

• A patch of your changes against this original, unmodified source.

The patch should include all your changes for MINIX (including build.minix script, .descr, .rdeps, .bdeps etc). The patch should be in unified diff format, i.e. install the GNU diff package and use something like:

/usr/local/bin/diff -urN original_src_dir modified_src_dir

Please review the patch carefully before sending. Please check that your patch doesn't include any extraneous changes and verify that it applies cleanly against the original, unmodified source package.

The “New Packages” tracker can be found here: New Packages Tracker.

You may also post an announcement on the Google newsgroup. Please do not post any large files to this group. Feedback should go to the author.

Keep in mind that reviewing new packages is (currently) a time-consuming process and it might take a while before we get around to processing yours. Thank you!