> Well, I would suspect that the NetBSD ports mechanism would have to be at
> least somewhat different from the FreeBSD version, owing to the desire to
> support so many architectures.

I'd actually be rather surprised if this were the case.  I've probably
either done or helped to integrate several hundred FreeBSD ports at
this point, and nearly _all_ the changes I've run into have been
BSD vs SomeOtherUN*X types of issues, not x86 vs other architecture
issues.

The few instances where the x86 platform's hardware has come into play
have been tied more to specific types of hardware support, like the
SCSI generic support for scanners in ports/graphics/hpscan or the
Voxware-using audio ports in ports/audio.  For those rare cases, the
NetBSD folks could either eschew the port entirely or figure out how
to become more compatible.

Since I mentioned audio, I should also note that we fully expect to be
running the OSS/Lite sound system in another 6 months or so anyway (if
not sooner - I'm being deliberately overconservative here), something
which would entirely remove that vestige of gratuitous incompatibily
with Linux and SCO's audio subsystem and also be something the NetBSD
folks would be encouraged to do as well.  Things have come a long way
since "voxware."

Finally, I can only note that OpenBSD [several NetBSD project members
cross themselves] seems to have adopted the FreeBSD ports collection
while clearly maintaining their goal of cross-architecture support, so
the two can't be all that mutually exclusive!

In any case, this certainly isn't something I'm going to fight about -
the NetBSD project has always been free to make its own decisions and
I wouldn't have it any other way, I'm simply pointing out what appears
to be another gratuitous divergence in the making.

					Jordan