DragonFly kernel List (threaded) for 2005-09
Re: PKGSRC will be officially supported as of the next release
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.