Patch framework

[Matthew Dillon]

:We're already dependent on pkgsrc.  Not so much that we couldn't build a
:system without it, but not having some sort of third-party packaging
:system would make DragonFly a lot less useful.  If the people who work on
:pkgsrc somehow decided to do something that broke pkgsrc on DragonFly,
:we'd have to look for an alternative anyway.

    I don't think the pkgsrc dependance is an issue.  I mean, for all intents
    and purposes our current contrib/ scheme is nothing more then a snapshot
    of some piece of contrib code anyway.  How does this differ from
    keeping a binary package around?  We would distribute these binary
    packages in binary-package-form as well as pre-installed on the 
    distribution CD, and we would also copy them onto the hard drive as part
    of the installation process.  

    Thus a system operator would always have the ability to reinstall the
    prebuilt packages without having to rely on a fresh pkgsrc build.

    It would be no more error prone then contrib snapshot methodology we
    use now, in my view.  It would require less upkeep and it would also
    give people running older systems the opportunity to upgrade portions 
    of those systems (e.g. sendmail, bind) from pkgsrc without having to
    worry about build tree interference.

    The nrelease build already does something like this... it expects certain
    binary packages to be available and if they aren't it tells the user how
    to get them.  In the case of nrelease, I pre-build the binary packages
    and put them on the DragonFly master site.  Everyone who uses nrelease
    is dependant on those packages to some degree.

    What I propose is a slightly more sophisticated solution for
    buildworld/installworld.  Instead of maintaining the packages on a 
    master site, have buildworld maintain them somewhere (e.g. in /usr/obj),
    and give it the ability to either retrieve them from the master site or
    to build them from scratch (including creating the appropriate package
    building environment to be able to do so without effecting the 
    currently running system).  As long as the ABIs do not change, you 
    would not have to rebuild these packages every single time you run a
    buildworld... the default would be to use the ones that already
    exist unless an option is given.

    Believe me, I have the same jitters over building packages from source
    as any other person.... but those jitters do not extend to binary
    packages.  Once built, a binary package is a very stable entity.  The
    fewer dependancies it has, the more stable it is.  I can safely say
    that the binary packages we are talking about do not have very many
    dependancies.

						-Matt