Xml in packaging system

David Leimbach leimy2k at mac.com
Fri Oct 31 12:42:37 PST 2003

This is very cool... At first glance it looks like
"press record"
build the package.
"stop recording"
Now you have a set of port rules?

Am I way off?

If not I really like it :).  How would this differ from expect?

I think I missed something.

On Oct 31, 2003, at 12:25 PM, Matthew Dillon wrote:
    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 
    which you have already installed on the system):

    % vfsrecord "build_depend"
    ok, recording mappings as 'build_depend'
    % vfsmap libgettextsrc:0.12.11
    % vfsmap libexpat		(map in the highest installed version)
    % vfsmap libc
    % 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 
    additional required elements.

    Modifications to the port distribution itself could also be done 
    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 
    memory (sufficient as long as no more then 2G worth of changes are 

    % vfsunion ~dillon/original_distribution work

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

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

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

    Ok.  So there you have it, you now have the VFS environment and the
    patches required to build your new port!
    Similar action would be taken for install and run-time 
    Run-time dependancies would be more restrictive since under normal
    conditions you might not want to have to run every port wrapped in 
    VFS.  e.g. simple ports like when you run 'less'.  But more 
    ports, like OpenOffice, might always run in some sort of VFS 

    Note that the VFS environment I am contemplating does not take over
    the entire filesystem space.  That is, in the above example, the 
    directories /usr/local/lib and /usr/local/bin would be selectively 
    and/or modified within the VFS but other directories, like your 
    directory for example (really all other directories not involved 
    mapping operations) would simply be passed through.  You would 
have to
    explicitly tell the VFS to map something as a union in order for 
the VFS
    to record your modifications within that target.

    In anycase, that is my idea... to approach it from the port 
    point of view rather then from a technical standpoint.

					Matthew Dillon
					<dillon at xxxxxxxxxxxxx>

More information about the Kernel mailing list