Our policy is that we accept binaries only from pkgsrc developers to guarantee that the packages don't contain any trojan horses etc. This is not to annoy anyone but rather to protect our users! You're still free to put up your home-made binary packages and tell the world where to get them. NetBSD developers doing bulk builds and wanting to upload them please see Section 7.3.8, “Uploading results of a bulk build”.

First, check that your package is complete, compiles and runs well; see Chapter 20, Debugging and the rest of this document. Next, generate an uuencoded gzipped tar(1) archive that contains all files that make up the package. Finally, send this package to the pkgsrc bug tracking system, either with the send-pr(1) command, or if you don't have that, go to the web page http://www.NetBSD.org/support/send-pr.html, which contains some instructions and a link to a form, where you can submit packages.

In the form of the problem report, the category should be “pkg”, the synopsis should include the package name and version number, and the description field should contain a short description of your package (contents of the COMMENT variable or DESCR file are OK). The uuencoded package data should go into the “fix” field.

If you want to submit several packages, please send a separate PR for each one, it's easier for us to track things that way.

Alternatively, you can also import new packages into pkgsrc-wip (“pkgsrc work-in-progress”); see the homepage at http://pkgsrc-wip.sourceforge.net/ for details.

Please note all package additions, updates, moves, and removals in pkgsrc/doc/CHANGES-YYYY. It's very important to keep this file up to date and conforming to the existing format, because it will be used by scripts to automatically update pages on www.NetBSD.org and other sites. Additionally, check the pkgsrc/doc/TODO file and remove the entry for the package you updated or removed, in case it was mentioned there.

When the PKGREVISION of a package is bumped, the change should appear in pkgsrc/doc/CHANGES-YYYY if it is security related or otherwise relevant. Mass bumps that result from a dependency being updated should not be mentioned. In all other cases it's the developer's decision.

There is a make target that helps in creating proper CHANGES-YYYY entries: make changes-entry. It uses the optional CTYPE and NETBSD_LOGIN_NAME variables. The general usage is to first make sure that your CHANGES-YYYY file is up-to-date (to avoid having to resolve conflicts later-on) and then to cd to the package directory. For package updates, make changes-entry is enough. For new packages, or package moves or removals, set the CTYPE variable on the command line to "Added", "Moved", or "Removed". You can set NETBSD_LOGIN_NAME in mk.conf if your local login name is not the same as your NetBSD login name. Don't forget to commit the changes to pkgsrc/doc/CHANGES-YYYY!

This section is only of interest for pkgsrc developers with write access to the pkgsrc repository. Please remember that cvs imports files relative to the current working directory, and that the pathname that you give the cvs import command is so that it knows where to place the files in the repository. Newly created packages should be imported with a vendor tag of “TNF” and a release tag of “pkgsrc-base”, e.g:

$ cd .../pkgsrc/category/pkgname
$ cvs import pkgsrc/category/pkgname TNF pkgsrc-base

Remember to move the directory from which you imported out of the way, or cvs will complain the next time you “cvs update” your source tree. Also don't forget to add the new package to the category's Makefile.

The commit message of the initial import should include part of the DESCR file, so people reading the mailing lists know what the package is/does.

For new packages, “cvs import” is preferred to “cvs add” because the former gets everything with a single command, and provides a consistent tag.

Please always put a concise, appropriate and relevant summary of the changes between old and new versions into the commit log when updating a package. There are various reasons for this:

Please also recognize that, just because a new version of a package has been released, it should not automatically be upgraded in the CVS repository. We prefer to be conservative in the packages that are included in pkgsrc - development or beta packages are not really the best thing for most places in which pkgsrc is used. Please use your judgement about what should go into pkgsrc, and bear in mind that stability is to be preferred above new and possibly untested features.