A port is a directory containing the files needed for building a package using '''pkgmk'''. This means that this directory at least has the files %fn%Pkgfile%% (which is the package build description) and %fn%.footprint%% (which is used for regression testing and contains a list of files this package is expected to contain once it is built). Further, a port directory can contain patches and/or other files needed for building the package. It is important to understand that the actual source code for the package is not necessarily present in port directory. Instead the %fn%Pkgfile%% contains an URL which points to a location where the source can be downloaded.
The use of the word ''port'' in this context is borrowed from the BSD world, where a ''port'' refers to a program that has been ported to a system or platform. The word can sometimes be a bit misleading since most programs require no actual porting to run on CRUX (or on Linux in general).
The term ''Ports System'' refers to a remote repository containing ports and a client program capable of downloading ports from that repository. The administrator of a CRUX system runs the '''ports(8)''' bash script to download ports from the remote repository and place them in %fn%/usr/ports/%%. The '''ports''' script uses rsync(1) or httpup(1) or git(1) to do the actual downloading/synchronization.
%fn%core%%, %fn%opt%%, %fn%xorg%% and %fn%compat-32%% are the four primary collections of CRUX. They're maintained by the CRUX development team which ensures that they're consistent and working well together. The first three are enabled by default. The %fn%compat-32%% collection is disabled by default and contains 32-bit compatibility ports.
The %fn%contrib%% collection is a collection which is provided by experienced port maintainers: some are part of the CRUX development team, while others are regular users. Its goal is to reduce the number of duplicate ports provided in the individual collections. If you're a seasoned port maintainer, you might even want to [[ContribRules|join the contrib team]].
Using [[https://crux.nu/Wiki/SettingUpAnHttpupRepo|HttpUp]] or [[https://crux.nu/Wiki/SettingUpAGitRepo|git]], every user can publish his or her own ports easily; the
only requirement for that is some webspace to upload the ports. Maintaining an HttpUp repository of ports, which you've tested and gotten successfully running, is a simple way to contribute back to the CRUX community.
When CRUX is installed for the first time the local ports structure (%fn%/usr/ports/%%) is empty. To bring your local ports structure up to date you use the '''ports''' utility with the '''-u''' option. Example:
The '''-u''' option means update, and tells '''ports''' to contact the ports repository and download new and updated ports. The output from this execution is something like this:
When the local ports structure has been updated the directory %fn%/usr/ports/%% will contain at least two collections, %fn%core%% and %fn%opt%%. Under each of these directories you will find ports. You can simply browse around in the
If you are looking for a specific package, a command like '''ports -l | grep sendmail''' provides a straightforward way to find out if the package is available and if so in which collection it is located. More complicated searches (eg., based on footprint, description, or maintainer) can be performed using '''prt-get'''.
To find out if the ports structure carries ports that are different (likely newer) compared to the versions currently installed, you can use the option '''-d'''. If differences are found (in either 'version' or 'release'), the output from the above command could look something like this:
The '''-d''' option means download missing source files and tells '''pkgmk''' to download the source(s) specified in the Pkgfile (in case the source is already downloaded, this option is ignored). When the download is completed the package will be built. If the package was built successfully you can use '''pkgadd''' to install or upgrade it. Example:
-> If you enable [[#NonRootBuilding | building ports as an unprivileged user]] and give that user write permissions on the directories for pkgmk {sources, work, packages}, the unprivileged user will be able to create a package but not to exercise the '''-i''' and '''-u''' options of '''pkgmk'''. There are forks of pkgmk that automatically invoke '''sudo''' or '''doas''' when performing the '''pkgadd''' step, but these forks are not part of the official CRUX utilities at this time.
As previously mentioned, the 'contrib' collection contains useful ports of experienced port maintainers. Since they are not provided by the CRUX development team, you should be slightly more critical with respect to quality and security. However, members with write permissions for 'contrib' are usually well-known and active in the CRUX community.
You will probably also want to let '''prt-get''' know about the newly-enabled 'contrib' tree. This can be done by editing %fn%/etc/prt-get.conf%% and uncommenting the line @@prtdir /usr/ports/contrib@@ (i.e. remove the hashmark in the beginning of the line). After that, it should look like this:
Building packages requires root privileges in order to create files with the correct owner and group. This is a security concern because a malicious or badly designed port can run arbitrary commands when its Pkgfile is sourced by the shell. The '''fakeroot''' command provides a way to build ports as normal user. Particularly when you build packages from user contributed repositories you are advised to use '''fakeroot''':
* You can also make '''prt-get''' use '''fakeroot''', by modifying the line in %fn%prt-get.conf%% that contains @@makecommand@@. This line would allow a non-root user running '''prt-get''' to create packages with no footprint mismatches (wrong owner/group), but the installation of these packages (and the running of pre-/post-install scripts) needs additional privileges.
* Additional lines in %fn%prt-get.conf%%, defining @@addcommand@@ and @@runscriptcommand@@ with '''sudo''' or '''doas''', is one way to let '''prt-get''' work properly for a non-root user.
* Another possibility is to write a '''sudo''' or '''doas''' configuration that grants permission to run '''prt-get''' itself, and then as a non-root user you would always run '''sudo prt-get''' rather than '''prt-get''' directly.
* Read the man pages for %fn%prt-get.conf%% and %fn%sudo/doas%% to learn how these pieces fit together, and choose whichever option you like best. To give extra scrutiny to ports you find outside the official repositories, it helps to restrict yourself to the low-level commands '''pkgmk''' and '''pkgadd''' rather than the wrapper program '''prt-get'''. This practice forces you to be in the directory of the unofficial port, where the %fn%Pkgfile%% source array and build function are more likely to receive your careful attention.
Regarding package and ports management there are many tasks which can be done in several steps with the CRUX standard tools introduced above. The %fn%opt%% repository contains a port called [[PrtUtils|prt-utils]] with many such scripts. Other combinations of low-level tools, using UNIX pipes, command substitution, and text processing utilities, can be found in the bug tracker, the mailing list, and IRC logs. Efforts are underway to bring this diaspora of institutional knowledge into a central place, such as the EXAMPLES section of the most relevant man page.
