Re: Xml in packaging system

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:I would imagine you could do something like
:%vfsmap -w /pkgbuild /
:
:And after running make install, plists are just
:%find /pkgbuild
:
:This removes the need for
:=2E/configure --prefix=3D/usr/local
:make install DESTDIR=3D/pkgbuild
:
:and programs that dont support these directives. =20
:Thats was my idea of how things would be done.  Like gentoo sandboxing, but=
:=20
:much better.
:
:=2DCraig

    One can also theoretically run an entire subsystem within a VFS.  So,
    for example:

    login.conf:
	...
	vfsenviron=stduser.vfs

    stduser.vfs might map other .vfs files representing all the ports in the
    system in order to produce what the user sees as a complete system.

    I am going a bit overboard, but it *would* be possible to do this.  In
    particular, those VFS's that only do mappings could operate entirely
    within the kernel and not represent any significant overhead.

    # massive overkill, but a good example:

    stduser.vfs {
	stdincludes.vfs
	stdbin.vfs
	stdusrbin.vfs
	mozilla-HEAD-run.vfs
	openoffice-HEAD-run.vfs
	X-HEAD-devel.vfs	# development libraries
	X-HEAD-run.vfs
    }

    If you think about it, if even fairly small packages use this sort of
    methodology we could institute a standardized 'installation directory'
    location for the *physical* location of the files related to a port.

    e.g. the files related to a port could be installed in, say,
    /usr/local/ports/PORTNAME-VERSION/

    And the VFS mapping would map the files and directories in the above
    directory to the locations expected by user programs.

    Again, this is overkill of an example, but it would work.  And that's
    what I want to be able to accomplish the most... write a single 
    mechanism that is flexible enough to support several different sorts
    of abstractions.
	
						-Matt