PKGSRC will be officially supported as of the next release

[Matthew Dillon]

    It would be kinda hard since I don't frequent IRC :-).  In fact, I think
    I denied the last two or three requests that came from IRCland.  Also,
    people should be aware that nobody has a free pass in the project, not
    even me if enough people band together to sway what they might think is
    a bad decision.  I impose stringent requirements on all the work that
    goes into the tree, especially big pieces such as those done by Joerg and
    Jeffrey.  It took Jeff a *LOT* of arguing and even real code 
    demonstrations to get OBJCACHE in, and I'm still not satisfied with its
    robustness even now.  I almost backed out Joerg's stat changes when he
    committed them without the dirent changes, and I made him revert a good
    chunk of the dirent API modifications he had in pre-commit versions of
    his patch set.

    In anycase, I think most people know that it is very difficult to sway
    me on anything, let alone 'political pressure' of any kind.  It takes
    a very good argument and often real code or demonstrated viability to
    make me change my mind.  I have a vision for DragonFly and we've pretty
    much followed it from day one.  But I also have to be pragmatic... no plan
    is going to survive entirely intact over a multi-year project, and
    the packaging system is one that clearly had to change.

    Demonstrated viability and significant effort by multiple developers
    over MONTHS (not days, MONTHS), not to mention my own take on the 
    PKGSRC development people (1), has persuaded me that it's the way to go.
    I would love to have been able to have designed my own packaging system
    from scratch... when I first started DragonFly most of what Jordan and
    I talked about as I was bouncing ideas off of him was the packaging 
    system.  I gave us a year and half to get there, and built DFPORTS as
    a stop-gap to give us time, but it was simply not going to happen the
    way I originally dreamed.  I'm not sad about it... there are many reasons
    why we can't do it the way I originally wanted, mostly having to do with
    the fact that 100% of my time is spent managing the project and working
    on the kernel, leaving 0% available to design, implement, and support
    a wholely new packaging system.  Likewise, as time went on it became quite
    clear that ports was not going to work for us.  The developers we had
    building overrides or trying to create fresh ports rapidly got overwhelmed,
    and the likelihood that we would be able to continue to leverage off
    the FreeBSD ports collections, much of which was becoming more and more
    FreeBSD-centric, was clearly getting smaller and smaller.  Going with 
    PKGSRC is a confluence of many things.  Nobody should try to simplify
    it into a single reason to argue for or against it.  That just
    isn't the reality.

     note 1: I truely believe that the PKGSRC project developers are far
     more open and dedicated to making PKGSRC truely multi-platform and 
     multi-architecture then the FreeBSD developers are in making ports that.
     We need that kind of dedication to help us maintain our own contributions,
     because we simply cannot go it alone.

    In anycase, that's my position on the matter.  With this under our belt
    we can move on without further uncertainty in the packaging department.

    --

    The only argument left is where to install the packages, but if people
    think a moment it should be clear that we want to put them somewhere
    other then /usr/local.  /usr/pkg is not a bad choice.  But the MAIN
    reason I don't want to use /usr/local is because I want /usr/local
    available to us for some sort of system-supported symbolic link / VARSYM
    scheme in addition to the desire to separate automated and manaual
    installation sets.  We have the ability to create a clearly delineated
    layering here.  I would far prefer that sysop hacks and related 
    manipulation occur in /usr/local and that /usr/pkg only ever be touched
    by the packaging system itself.  I think when one views the issue in 
    those terms that it is clear we want the packaging system to install
    into something like /usr/pkg.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>