Re: Xml in packaging system

[David Leimbach <leimy2k@xxxxxxx>]

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.

Dave
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 
> 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
>
>     --------------------
>
>     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 
> dependancies.
>     Run-time dependancies would be more restrictive since under normal
>     conditions you might not want to have to run every port wrapped in 
> a
>     VFS.  e.g. simple ports like when you run 'less'.  But more 
> involved
>     ports, like OpenOffice, might always run in some sort of VFS 
> environment.
>
>     Note that the VFS environment I am contemplating does not take over
>     the entire filesystem space.  That is, in the above example, the 
> mainstream
>     directories /usr/local/lib and /usr/local/bin would be selectively 
> enabled
>     and/or modified within the VFS but other directories, like your 
> home
>     directory for example (really all other directories not involved 
> with
>     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 
> maintainer's
>     point of view rather then from a technical standpoint.
>
> 					-Matt
> 					Matthew Dillon
> 					<dillon@xxxxxxxxxxxxx>