13.1. Adding a New Port | |
13.1.1. | How do I add a new port? |
First, please read the section about repository copies. The easiest way to add a new port is to use the
| |
13.1.2. | Any other things I need to know when I add a new port? |
Check the port, preferably to make sure it compiles and packages correctly. This is the recommended sequence: # make install
# make package
# make deinstall
# pkg_add
# make deinstall
# make reinstall
# make package The Porters Handbook contains more detailed instructions. Use portlint(1) to check the syntax of the port. You do not necessarily have to eliminate all warnings but make sure you have fixed the simple ones. If the port came from a submitter who has not contributed to the Project before, add that person's name to the Additional Contributors section of the FreeBSD Contributors List. Close the PR if the port came in as a PR. To close
a PR, just do | |
13.2. Removing an Existing Port | |
13.2.1. | How do I remove an existing port? |
First, please read the section about repository copies. Before you remove the port, you have to verify there are no other ports depending on it.
Alternatively, you can use the
| |
13.3. Re-adding a Deleted Port | |
| |
13.3.1. | How do I re-add a deleted port? |
This is essentially the reverse of deleting a port.
Tip:
| |
13.4. Repository Copies | |
| |
13.4.1. | When do we need a repository copy? |
When you want to add a port that is related to
any port that is already in the tree in a separate
directory, you have to do a repository copy.
Here related means
it is a different version or a slightly modified
version. Examples are
Another example is when a port is moved from one subdirectory to another, or when you want to change the name of a directory because the author(s) renamed their software even though it is a descendant of a port already in a tree. | |
13.4.2. | What do I need to do? |
With Subversion, a repo copy can be done by any committer:
| |
13.5. Ports Freeze | |
13.5.1. | What is a “ports freeze”? |
Before a release, it is necessary to restrict commits to the ports tree for a short period of time while the packages and the release itself are being built. This is to ensure consistency among the various parts of the release, and is called the “ports freeze”. For more information on the background and policies surrounding a ports freeze, see the Portmgr Quality Assurance page. | |
13.5.2. | What is a “ports slush” or “feature freeze”? |
During a release cycle the ports tree may be in a “slush” state instead of in a hard freeze. The goal during a slush is to reach a stable ports tree to avoid rebuilding large sets of packages for the release and to tag the tree. During this time “sweeping changes” are prohibited unless specifically permitted by portmgr. Complete details about what qualifies as a sweeping change can be found on the Portmgr Implementation page. The benefit of a slush as opposed to a complete freeze is that it allows maintainers to continue adding new ports, making routine version updates, and bug fixes to most existing ports, as long as the number of affected ports is minimal. For example, updating the shared library version on a port that many other ports depend on. | |
13.5.3. | How long is a ports freeze or slush? |
A freeze only lasts long enough to tag the tree. A slush usually lasts a week or two, but may last longer. | |
13.5.4. | What does it mean to me? |
During a ports freeze, you are not allowed to commit anything to the tree without explicit approval from the Ports Management Team. “Explicit approval” here means that you send a patch to the Ports Management Team for review and get a reply saying, “Go ahead and commit it.” Not everything is allowed to be committed during a freeze. Please see the Portmgr Quality Assurance page for more information. Note that you do not have implicit permission to fix a port during the freeze just because it is broken. During a ports slush, you are still allowed to commit but you must exercise more caution in what you commit. Furthermore a special note (typically “Feature Safe: yes”) must be added to the commit message. | |
13.5.5. | How do I know when the ports slush starts? |
The Ports Management Team will send out warning messages to the FreeBSD ports mailing list and FreeBSD committer's mailing list announcing the start of the impending release, usually two or three weeks in advance. The exact starting time will not be determined until a few days before the actual release. This is because the ports slush has to be synchronized with the release, and it is usually not known until then when exactly the release will be rolled. When the slush starts, there will be another announcement to the FreeBSD ports mailing list and FreeBSD committer's mailing list, of course. | |
13.5.6. | How do I know when the freeze or slush ends? |
A few hours after the release, the Ports Management Team will send out a mail to the FreeBSD ports mailing list and FreeBSD committer's mailing list announcing the end of the ports freeze or slush. Note that the release being cut does not automatically indicate the end of the freeze. We have to make sure there will be no last minute snafus that result in an immediate re-rolling of the release. | |
13.6. Creating a New Category | |
13.6.1. | What is the procedure for creating a new category? |
Please see
Proposing a New Category in the Porter's
Handbook. Once that procedure has been followed and the
PR has been assigned to Ports Management Team
| |
13.6.2. | What do I need to do to implement a new physical category? |
It is not necessary to manually update the
ports web
pages to reflect the new category. This is
now done automatically via your change to
| |
13.6.3. | What do I need to do to implement a new virtual category? |
This is much simpler than a physical category. You only need to modify the following:
| |
13.7. Miscellaneous Questions | |
| |
13.7.1. | How do I know if my port is building correctly or not? |
First, go check http://pointyhat.FreeBSD.org/errorlogs/. There you will find error logs from the latest package building runs on all supported platforms for the most recent branches. However, just because the port does not show up
there does not mean it is building correctly. (One of
the dependencies may have failed, for instance.) The
relevant directories are available on
errors error logs from latest <major_version> run on <arch>
logs all logs from latest <major_version> run on <arch>
packages packages from latest <major_version> run on <arch>
bak/errors error logs from last complete <major_version> run on <arch>
bak/logs all logs from last complete <major_version> run on <arch>
bak/packages packages from last complete <major_version> run on <arch> Basically, if the port shows up in
| |
13.7.2. | I added a new port. Do I need to add it to the
|
No, | |
13.7.3. | Are there any other files I am not allowed to touch? |
Any file directly under | |
13.7.4. | What is the proper procedure for updating the checksum for a port's distfile when the file changes without a version change? |
When the checksum for a port's distfile is updated due to the author updating the file without changing the port's revision, the commit message should include a summary of the relevant diffs between the original and new distfile to ensure that the distfile has not been corrupted or maliciously altered. If the current version of the port has been in the ports tree for a while, a copy of the old distfile will usually be available on the ftp servers; otherwise the author or maintainer should be contacted to find out why the distfile has changed. |
This, and other documents, can be downloaded from http://ftp.FreeBSD.org/pub/FreeBSD/doc/
For questions about FreeBSD, read the
documentation before
contacting <questions@FreeBSD.org>.
For questions about this documentation, e-mail <doc@FreeBSD.org>.