Submitting and Committing
Submitting your packages
You have to separate between binary and normal
(source)
packages here:
precompiled binary packages
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 .
packages
First, check that your package is complete, compiles and runs well;
see and the rest of this document. Next,
generate an uuencoded gzipped &man.tar.1; archive, preferably with all files
in a single directory.
Finally, send-pr with category pkg
, a
synopsis which includes the package name and version number, a short
description of your package (contents of the COMMENT variable or DESCR
file are OK) and attach the archive to your PR.
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 for details.
General notes when adding, updating, or removing packages
Please note all package additions, updates, moves, and removals
in pkgsrc/doc/CHANGES. 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.
There is a make target that helps in creating proper
CHANGES 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
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 /etc/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!
Committing: Importing a package into CVS
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:
&uprompt; cd .../pkgsrc/category/pkgname
&uprompt; 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.
Updating a package to a newer version
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:
A URL is volatile, and can change over time. It may go away completely
or its information may be overwritten by newer information.
Having the change information between old and new versions in our CVS
repository is very useful for people who use either cvs or anoncvs.
Having the change information between old and new versions in our CVS
repository is very useful for people who read the pkgsrc-changes mailing
list, so that they can make tactical decisions about when to upgrade
the package.
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.
Moving a package in pkgsrc
Make a copy of the directory somewhere else.
Remove all CVS dirs.
Alternatively to the first two steps you can also do:
% cvs -d user@cvs.NetBSD.org:/cvsroot export -D today pkgsrc/category/package
and use that for further work.
Fix CATEGORIES and any
DEPENDS paths that just did ../package
instead of ../../category/package
.
cvs import the modified package in the new
place.
Check if any package depends on it:
% cd /usr/pkgsrc
% grep /package */*/Makefile* */*/buildlink*
Fix paths in packages from step 5 to point to new location.
cvs rm (-f) the package at the old location.
Remove from oldcategory/Makefile.
Add to newcategory/Makefile.
Commit the changed and removed files:
% cvs commit oldcategory/package oldcategory/Makefile newcategory/Makefile
(and any packages from step 5, of course).