Re: Xml in packaging system

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:Well, I think it would only record changes to the vfs layout - not
:every action you took, like a screen-scrubber would.
:
:But I'm confused too.  Wouldn't entire files be sucked into the file
:build_depends.vfs?  How would you tell it that /usr/local/lib/foo.a
:is just a dependency, to be built by some other port/package as a
:prerequisite, and not something to be created outright by the 'patch'?
:
:At any rate, I guess this means slogging through the meaty stuff will
:have to wait until VFS is working.  But, it doesn't address the other
:details about ports/packages - metadata, file format, and so forth, so
:we still have plenty we can bikeshed about in the meantime :)
:
:-Chris

    There are two things going on:

    (1) Dependancies are other VFS-generated blah.vfs files.  They would be
	'mapped' into the current VFS as a dependancy, not actually copied
	into the current VFS.

    (2) The only 'top-layer' modifications made to the current VFS, other
	then the mappings in (1), would reflect *ONLY* the requirements of
	the current package.

	build time:	mappings + package source code + the modifications
			that were made to get it to compile on DragonFly.

	install time:	possibly additional mappings required to install
			(e.g. one might need 'perl' to install a third
			party package but the third party package itself
			doesn't need perl at run time)

	run time:	A totally different set of mappings + package
			install image.

    Lets take the build-time situation first, since it makes a great
    example.  Lets say you are building mozilla.

	* Mozilla depends on other libraries, which you have already
	  generated ports for.  So you just 'map' these library
	  dependancies in for the purposes of doing the build.

	* The Mozilla base source for version XYZ is distributed by a
	  third party.  You create a port that represents the broken-out
	  base source (which can then be abstracted at a higher level
	  to mean 'pull down this mozillaBLAHXYZ.tgz from host FUBAR and
	  tar xvzpf it').

	  Call it:	mozilla-base-XYZ

	* With the base source available as a port you can simply map it
	  in.  Now you 'modify' the base source to make it compile under
	  DragonFly.

	  Call it:	mozilla-dfly-XYZ

    The 'patch set' for mozilla-base-XYZ would be zippo because we would
    have a VFS option to 'tar xvzpf' the archive into the VFS's memory
    filesystem, so this devoles into a fetch-like entity similar to what
    we see with the FreeBSD packages system.

    The 'patch set' for mozilla-dfly-XYZ would represent only the 
    modifications we have made to the source base in order to get it to
    compile on DragonFly.

    So, as you can see here, I am attempting to make things as easy as 
    possible for the person responsible for doing the port and, also,
    I am attempting to make things as easy as possible for anyone who wishes
    to maintain the port.  Maintaining the port can be as simple as 
    loading up mozilla-dfly-XYZ VFS, making *additional* modifications,
    and then just telling the VFS to save its state again.  i.e. no messing
    with manual patch set generation just to make a small change here and
    there like has to be done with the FreeBSD ports system.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>