When a package is created, it is put under /usr/ports/packages/All and links are made from one or more subdirectories of /usr/ports/packages. The names of these subdirectories are specified by the variable CATEGORIES. It is intended to make life easier for the user when he is wading through the pile of packages on the FTP site or the CDROM. Please take a look at the current list of categories and pick the ones that are suitable for your port.
This list also determines where in the ports tree the port is imported. If you put more than one category here, it is assumed that the port files will be put in the subdirectory with the name in the first category. See below for more discussion about how to pick the right categories.
Here is the current list of port categories. Those marked with an asterisk (*) are virtual categories--those that do not have a corresponding subdirectory in the ports tree. They are only used as secondary categories, and only for search purposes.
Note: For non-virtual categories, you will find a one-line description in the COMMENT in that subdirectory's Makefile.
|accessibility||Ports to help disabled users.|
|afterstep*||Ports to support the AfterStep window manager.|
|arabic||Arabic language support.|
|cad||Computer aided design tools.|
|chinese||Chinese language support.|
|comms||Communication software.||Mostly software to talk to your serial port.|
|converters||Character code converters.|
|deskutils||Things that used to be on the desktop before computers were invented.|
|devel||Development utilities.||Do not put libraries here just because they are libraries--unless they truly do not belong anywhere else, they should not be in this category.|
|editors||General editors.||Specialized editors go in the section for those tools (e.g., a mathematical-formula editor will go in math).|
|emulators||Emulators for other operating systems.||Terminal emulators do not belong here--X-based ones should go to x11 and text-based ones to either comms or misc, depending on the exact functionality.|
|finance||Monetary, financial and related applications.|
|french||French language support.|
|ftp||FTP client and server utilities.||If your port speaks both FTP and HTTP, put it in ftp with a secondary category of www.|
|german||German language support.|
|gnome*||Ports from the GNOME Project.|
|gnustep*||Software related to the GNUstep desktop environment.|
|hamradio*||Software for amateur radio.|
|haskell*||Software related to the Haskell language.|
|hebrew||Hebrew language support.|
|hungarian||Hungarian language support.|
|ipv6*||IPv6 related software.|
|irc||Internet Relay Chat utilities.|
|japanese||Japanese language support.|
|java||Software related to the Java language.||The java category shall not be the only one for a port. Save for ports directly related to the Java language, porters are also encouraged not to use java as the main category of a port.|
|kde*||Ports from the K Desktop Environment (KDE) Project.|
|kld*||Kernel loadable modules.|
|korean||Korean language support.|
|linux*||Linux applications and support utilities.|
|lisp*||Software related to the Lisp language.|
|math||Numerical computation software and other utilities for mathematics.|
|misc||Miscellaneous utilities||Basically things that do not belong anywhere else. If at all possible, try to find a better category for your port than misc, as ports tend to get overlooked in here.|
|net||Miscellaneous networking software.|
|net-im||Instant messaging software.|
|net-mgmt||Networking management software.|
|net-p2p||Peer to peer network applications.|
|news||USENET news software.|
|palm||Software support for the Palm™ series.|
|parallel*||Applications dealing with parallelism in computing.|
|pear*||Ports related to the Pear PHP framework.|
|perl5*||Ports that require Perl version 5 to run.|
|plan9*||Various programs from Plan9.|
|polish||Polish language support.|
|ports-mgmt||Ports for managing, installing and developing FreeBSD ports and packages.|
|portuguese||Portuguese language support.|
|Printing software.||Desktop publishing tools (previewers, etc.) belong here too.|
|python*||Software related to the Python language.|
|ruby*||Software related to the Ruby language.|
|rubygems*||Ports of RubyGems packages.|
|russian||Russian language support.|
|scheme*||Software related to the Scheme language.|
|science||Scientific ports that do not fit into other categories such as astro, biology and math.|
|shells||Command line shells.|
|spanish*||Spanish language support.|
|tcl*||Ports that use Tcl to run.|
|tcl80*||Ports that use Tcl version 8.0 to run.|
|tcl82*||Ports that use Tcl version 8.2 to run.|
|tcl83*||Ports that use Tcl version 8.3 to run.|
|tcl84*||Ports that use Tcl version 8.4 to run.|
|textproc||Text processing utilities.||It does not include desktop publishing tools, which go to print.|
|tk*||Ports that use Tk to run.|
|tk80*||Ports that use Tk version 8.0 to run.|
|tk82*||Ports that use Tk version 8.2 to run.|
|tk83*||Ports that use Tk version 8.3 to run.|
|tk84*||Ports that use Tk version 8.4 to run.|
|tkstep80*||Ports that use TkSTEP version 8.0 to run.|
|ukrainian||Ukrainian language support.|
|vietnamese||Vietnamese language support.|
|windowmaker*||Ports to support the WindowMaker window manager.|
|www||Software related to the World Wide Web.||HTML language support belongs here too.|
|x11||The X Window System and friends.||This category is only for software that directly supports the window system. Do not put regular X applications here; most of them should go into other x11-* categories (see below). If your port is an X application, define USE_XLIB (implied by USE_IMAKE) and put it in the appropriate category.|
|x11-fm||X11 file managers.|
|x11-fonts||X11 fonts and font utilities.|
|x11-wm||X11 window managers.|
|xfce*||Ports related to the Xfce desktop environment.|
As many of the categories overlap, you often have to choose which of the categories should be the primary category of your port. There are several rules that govern this issue. Here is the list of priorities, in decreasing order of precedence:
The first category must be a physical category (see above). This is necessary to make the packaging work. Virtual categories and physical categories may be intermixed after that.
Language specific categories always come first. For example, if your port installs Japanese X11 fonts, then your CATEGORIES line would read japanese x11-fonts.
Specific categories are listed before less-specific ones. For instance, an HTML editor should be listed as www editors, not the other way around. Also, you should not list net when the port belongs to any of irc, mail, mbone, news, security, or www, as net is included implicitly.
x11 is used as a secondary category only when the primary category is a natural language. In particular, you should not put x11 in the category line for X applications.
Emacs modes should be placed in the same ports category as the application supported by the mode, not in editors. For example, an Emacs mode to edit source files of some programming language should go into lang.
Ports which install loadable kernel modules should have the virtual category kld in their CATEGORIES line.
misc should not appear with any other non-virtual category. If you have misc with something else in your CATEGORIES line, that means you can safely delete misc and just put the port in that other subdirectory!
If your port truly does not belong anywhere else, put it in misc.
If you are not sure about the category, please put a comment to that effect in your send-pr(1) submission so we can discuss it before we import it. If you are a committer, send a note to the FreeBSD ports mailing list so we can discuss it first. Too often, new ports are imported to the wrong category only to be moved right away. This causes unnecessary and undesirable bloat in the master source repository.
As the Ports Collection has grown over time, various new categories have been introduced. New categories can either be virtual categories--those that do not have a corresponding subdirectory in the ports tree-- or physical categories--those that do. The following text discusses the issues involved in creating a new physical category so that you can understand them before you propose one.
Our existing practice has been to avoid creating a new physical category unless either a large number of ports would logically belong to it, or the ports that would belong to it are a logically distinct group that is of limited general interest (for instance, categories related to spoken human languages), or preferably both.
The rationale for this is that such a change creates a fair amount of work for both the committers and also for all users who track changes to the Ports Collection. In addition, proposed category changes just naturally seem to attract controversy. (Perhaps this is because there is no clear consensus on when a category is ``too big'', nor whether categories should lend themselves to browsing (and thus what number of categories would be an ideal number), and so forth.)
Here is the procedure:
Propose the new category on FreeBSD ports mailing list. You should include a detailed rationale for the new category, including why you feel the existing categories are not sufficient, and the list of existing ports proposed to move. (If there are new ports pending in GNATS that would fit this category, list them too.) If you are the maintainer and/or submitter, respectively, mention that as it may help you to make your case.
Participate in the discussion.
If it seems that there is support for your idea, file a PR which includes both the rationale and the list of existing ports that need to be moved. Ideally, this PR should also include patches for the following:
Makefiles for the new ports once they are repocopied
Makefile for the new category
Makefile for the old ports' categories
Makefiles for ports that depend on the old ports
(for extra credit, you can include the other files that have to change, as per the procedure in the Committer's Guide.)
Since it affects the ports infrastructure and involves not only performing repo-copies
but also possibly running regression tests on the build cluster, the PR should be
assigned to the Ports Management Team
If that PR is approved, a committer will need to follow the rest of the procedure that is outlined in the Committer's Guide.
Proposing a new virtual category should be similar to the above but much less involved, since no ports will actually have to move. In this case, the only patches to include in the PR would be those to add the new category to the CATEGORIES of the affected ports.
Occasionally someone proposes reorganizing the categories with either a 2-level structure, or some other kind of keyword structure. To date, nothing has come of any of these proposals because, while they are very easy to make, the effort involved to retrofit the entire existing ports collection with any kind of reorganization is daunting to say the very least. Please read the history of these proposals in the mailing list archives before you post this idea; furthermore, you should be prepared to be challenged to offer a working prototype.