Separation of Ports Build Process from Local Installation

• Student: TheronTarigo
• Mentor: BakulShah

This project aims to provide the capability of the FreeBSD ports infrastructure to safely and cleanly build ports and all their dependencies without superuser privileges, jails, or touching the installed system in anyway, in the interest of improving the safety, reliability, and repeatability of ports building without the administrative and resource overhead of a separated build host or jail.

This will bring the building capability of ports tree in line with what is already possible for FreeBSD base system: separate build vs. install workflow.

Currently this level of separation can only be accomplished in practice through chroot or Jail. This project will eliminate the need for cooperation of the root user since /usr/local will not need to be touched. To enable this, file accesses will be redirected to a location controlled by the ports build process through use of a userspace library to intercept file accesses.

This implementation takes the possibility of cross-building of ports into consideration as a long-term goal (far beyond end of GSoC due to the significant challenges and history of ports not taking this into consideration).

Where possible, the need for the userspace file interception hack should be eliminated, by switching to use of build tools supporting sysroot (this is analogous to desirability of sysroot-capable compiler vs. user-mode emulation for cross-arch compilation). The interception tool serves to cover otherwise uncooperative software.

Running the entire ports framework in a chroot (as is trivially possible) defeats the purpose of the project, since it only moves the problem of isolating each port's build environment from a physical host to a virtual one: Ports framework itself, not just a blanket chroot created by system administrator, should configure the build-environment of each port.

The commands needed for the ports infrastructure are logically separated as follows:

• Ports-framework commands, such as dependency calculation, fetching(*), patching(*), and packaging
  • (*) fetching and patching may require tools from ports in unusual cases
• Port-building commands, such as configure, make, (staged)install, tests

However, the existing implementation of the ports framework does not make this a clear distinction, since no such distinction has been needed for the existing capabilities of the ports framework. The distinction becomes important when the building processes of ports must occur in a specially prepared environment managed by the ports framework itself. Places where setup of this environment is needed roughly follows existing usage of ${CONFIGURE_ENV} / ${MAKE_ENV} / etc.

• Ports are built using PORTS_SEPARATED_BUILD=1 set (otherwise normal ports behavior is left alone as the default).
• Port building is started from unprivileged user. All compilation work is run as this user.
  • Superuser is requested for configuring and switching into chroot (switches back to user after entering chroot). This will be obviated by integration of userspace file redirection tool.
• Ports built as dependencies are installed to a working directory, not system-wide.
• Dependency resolution is patched to use this working directory.
• All port-building commands (configure scripts, compilers, interpreters) run under file redirection to see dependency install area instead of local system.
  • Current implementation of file redirection: chroot.

• Anything using standard configure/make procedure
• Builds using Autoreconf; requires patch to Mk/Uses/autoreconf.mk
• Builds using Cmake; requires patch to Mk/Uses/cmake.mk
• USES=perl; requires patch to Mk/Uses/perl5.mk
• USES=python; requires patch to Mk/Uses/python.mk

• Anything using custom targets in port's Makefile (requires patch for each port)