VFS and ports for maintainers

Matt Dillon explained what he wants the port-creation experience to be for a port maintainer, using VFS, quoted below:

“What I envision in a packaging system is something that makes the
port maintainer’s life as easy as possible.

Lets say you are developing a new port, libabcd, which depends on a
number of other libraries which are also ports in the system.

As a developer I want to be able to do something like this:

% vfsenvironment empty 'csh'

(Now you would be in a vfs-sandboxed shell. You can map-in other ports
which you have already installed on the system):

% vfsrecord "build_depend"
ok, recording mappings as 'build_depend'
% vfsmap libgettextsrc:0.12.11
ok
% vfsmap libexpat (map in the highest installed version)
ok
% vfsmap libc
ok
% vfsmap gmake
% vfsrename /usr/local/bin/gmake /usr/local/bin/make

Once you have built an environment you could then attempt to build
your new port natively simply by running the port’s native build
(at least initially). If things are missing you can vfsunmap and vfsmap
additional required elements.

Modifications to the port distribution itself could also be done through
the VFS. In this case the VFS would be acting like a unionfs in that it
would record whiteouts (deletions) and copy files that are modified into
a higher layer which would be stored in the VFS environment process’s
memory (sufficient as long as no more then 2G worth of changes are made).

% vfsunion ~dillon/original_distribution work

(make your modifications to the work. edit files, rm files, rename,
whatever).

When you are satisfied that the build is working you can save the vfs
state, which will also ‘diff’ any modifications you have made and record
file/directory deletions. The output file would be human readable and
human editable (though it’s easier for the developer to just enter the
vfs environment and make modifications within the environment)

% vfsrecord -w
all changes recorded in 'build_depend.vfs'
% exit