NetBSD pkgsrc Developer Information

pkgsrc freeze guidelines

Goals

The primary goal of the pkgsrc freeze is to produce the next stable branch of pkgsrc. Commits to the pkgsrc HEAD during a freeze should be aimed at reducing the open pkgsrc-related PR count, and reducing the number of broken packages in the bulk builds.

Rules

look here is a freeze on first
No infrastructure changes nor new packages should be committed. This includes non-trivial changes to buildlink3.mk files.
Package updates are only allowed for leaf packages or for packages with security issues. For non-leaf packages approval must be asked for and given (by pkgsrc-pmc) on the pkgsrc developers mailing list.
Approval requests to the pkgsrc developers mailing list must answer the following questions:
- Why is it critical to update this package for the upcoming branch?
- What changes should be expected between the current version and the updated version?
Commits should only be made to fix portability issues, build problems, or for addressing open PRs.
Commit messages should note explicitly why the commits were made during the freeze period, and if necessary, who gave the approval, e.g.:
- “Updated during the freeze to fix security issue noted at http://...; approved by ...”
- “Updated during the freeze to fix problem noted n pkg/NNNNN; approved by ...”
- “Fix build on Darwin due to issues with namesrv8_compat.h”
The pkgsrc “regress” and “doc” categories are exempt from the freeze.

Things to do when branching

Send an announcement to <netbsd-announce@NetBSD.org>.
Send an announcement to <www@NetBSD.org> or make the website announcement yourself (see this link).
Update htdocs/share/xml/misc.ent; regen htdocs/docs/software/packages.html and commit.
Update htdocs/developers/pkgsrc/index.xml; commit index.xml; regen index.html and commit.
Update is a freeze on wiki page.

Importing or updating packages

How to import a new package or update a package

This is explained in detail in the pkgsrc Guide.

Pulling up updates to branches

Critical bug fixes, security updates, and build fixes can be pulled up to the latest stable pkgsrc branch. Please forward the “cvs commit” mail from the pkgsrc-changes mailing list to the pullup address.

The pkgsrc pullup ticket tracking summaries are found by adding “index-pkgsrc.html” to the http://releng.NetBSD.org/ URL. (Not directly linked to avoid automated e-mail spidering.)

Bulk pkgsrc builds

Setting up a bulk pkgsrc build

The bulkbuild chapter of the pkgsrc guide describes how to set up a bulk pkgsrc build.

Currently Available Bulk Build Results

The results of various bulk pkgsrc builds are posted to the pkgsrc-bulk mailing list.

Providing binary packages for ftp.NetBSD.org (bulk-packages)

We need to coordinate providing a good set of binary packages for as many arch/osrev combinations as possible.

It is critical to ensure binary packages are built against the same set of depends to avoid install conflicts. The most practical way to arrange this is to use the bulk building system and upload the complete set of packages after every build.

Developers interested in assisting (all are invited) should subscribe to the <pkgsrc-bulk@NetBSD.org> list, and check localsrc/admin/bulk-packages for an available arch/osrev combination.

bulk-packages conventions:

When taking over an arch/osrev combination either start bulk building from scratch, or download the current set of binary packages from ftp.NetBSD.org to 'pre seed' the build process (most useful for slower architectures).
When uploading packages upload/rsync the entire set of bulk built packages, and delete any other packages for that arch/osrev from ftp.NetBSD.org.
If no longer able to handle a build, remove the entry from localsrc/admin/bulk-packages and notify pkgsrc-bulk.
Any developer can upload updated/new/security-fix packages to ftp.NetBSD.org, but they must be built against the set of binary packages already present for that arch/osrev.
Machines should run the latest minor release, or (recommended) track the release branch.

Note

This does not address the issue of new versions of binary packages not installing against a user's existing set of installed depends, or a updated depend potentially requiring an update of many other packages already installed in their machine.

Current options for that would be either freezing binary packages at tagged values, or having multiple binary package trees per arch/osrev. The former significantly reduces the utility of the binary packages, and the latter is not worth considering until we can get one consistent tree per arch/osrev.

Weekly pkgsrc checks

Weekly-pkgsrc script

Dan McMahill maintains a script that is run once a week to perform various pkgsrc consistency checks. The currentset of checks are:

DEPENDS — verifies that all {BUILD_}DEPENDS are set to valid versions.
distinfo — verifies distfile checksums and sizes, and that all patches are listed and their checksums match.
category makefiles — verifies all packages are listed in the category makefiles.
restricted binary packages — warns of any restricted binary packages.
vulnerable packages — verifies all vulnerable packages.

The results of these checks are emailed to NetBSD pkgsrc developers.

Miscellaneous

Handling the TODO List

There's a TODO list in the pkgsrc doc directory. Feel free to add, and especially remove items from there (after solving the mentioned problem, of course).

The pkg-bug-handler group

In order to manage the large number of pkgsrc-related problem reports each day, the “pkg-bug-handler” group has been created. See this page for details.

Back to NetBSD Developer Documentation