Re: Xml in packaging system

[Galen Sampson <galen_sampson@xxxxxxxxx>]

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.

This is excellent.  What you have described here describes the build 
configuration.  You mention that the install dependencies would be 
similar.  My question is about package lists.  When I install this port 
that I have set up would the package list stay static like the 
pkg-plist, or would it be possible to be dynamic (i.e. record what is 
installed and save that is the package list).  Say I'm about to `make 
install` or equivalent for this port I'm creating (libabcd in your 
example).  I assume it would be something like:

% vfsenvironment install_depend.vfs 'csh'
(Read in the environment that is required for installation of libabcd)

% vfsrecord "install"
% vfssnapshot ${PREFIX} install.vfssnap

Record current state of ${PREFIX} and save it in install.vfssnap for 
`diffing` after install.

% make install
% vfsunion install.vfssnap ${PREFIX}
% vfsrecord -w
all changes to ${PREFIX} recorded in 'install.vfs'
% exit

The reason a snapshot would need to be recorded is I can't vfsunion to 
something that doesn't exist yet.  Maybe instead of creating a snapshot 
there could be a `vfsmonitor ${PREFIX}` which would record changes to a 
filesystem instead of creating a (potentially huge) snapshot.  The idea 
is that packages with the same version do not always install the same 
files depending on which knobs are turned during configure, or 
equivalent.  I want the information about the package installed on my 
system to accurately reflect what was installed, not what the person who 
generated a plist had insalled for them.  I just had this happen with 
freebsd during installation of kerberos5.  I didn't install kerberos4 
compatibility, and hence the package would not be created because of 
missing files.  I had to edit the plist because I turned some knobs in a 
makefile.

regards,
Galen