Re: Xml in packaging system

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

: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:

    I think it can be both.  For the purpose of developing a new port or
    upgrading an existing port you can 'start' with everything currently
    installed on the system, then build the new port (or rebuild the existing
    port) using the current system configuration instead of the port's
    original configuration.

    It would be a simple function of rewiring the mappings.  Instead of 
    telling the VFS to map specific port dependancies you just tell the VFS
    to map your system as it stands.  Presumably you will have already 
    generated new ports for the library dependancies.

    e.g. lets say the current mozilla port depended on libiconf-1.1, and 
    someone (or you) just added a libiconf-1.2 port which you want mozilla
    to use.  What you do is you load up the mozilla build environment
    but then tell it to discard libiconf-1.1 and load in libiconf-1.2.

    This could be a single command 'vfs upgrade', which would replace 
    VFS mappings with the highest available version, for the purposes of
    development.

    You then build mozilla up, make sure everything works, and re-record
    the VFS and you are done.  Poof, mozilla is now upgraded.

    --

    Another alternative would be to just map every library under the 
    sun for development purposes (or at least every library that is
    currently installed on your system), build mozilla, and then
    tell the VFS to print out which of the hundreds of mappings were
    actually accessed by the build.  That would be a 'dynamic' way
    of generating the port.

    The port itself, once generated, would always be static... a known
    configuration producing a known working application.

: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

    Hmm.  This would require some thought.  There are plenty of ways to
    solve this problem, the real question is which way is the most
    beneficial?

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>