Has the port collection become to large to handle.

[Reko Turja]

I do use the ports mechanism on my FreeBSD systems exclusively due the 
possibility of making the system components meshing and working in 
unison instead of version and "dll-hell". And now and then I find some 
obscure port that fits the current needs - And again the ports system 
makes the whole process painless.

As such I see and feel very little need making the ports system smaller 
or more lightweight as there are other way to make downloading and using 
the ports in larger setups minor bindwidth or resource eater.

> However a reoganization could be in order... Currently we have:
> portbase/category/port/

Some kind of reorganization could be in order, if a good way doing it 
could be found. At one point I tended to drop the language and some 
other catergories from cvsup fetch, but it made building the INDEX next 
to impossible causing me reverting to full ports fetch again.

I dont know if indexing in separate categories or some such solution 
would be feasible, but of course fetchindex target makes the indexing of 
partial port trees feasible. Then of course there has to be good reasons 
for creating separate trees for non-english ports, but one thing I've 
thought is that if those could be put into main port build directory and 
enabled with a build knob or maybe making them some kind of metaports 
without needing their own directory hierarchy.

All in all the ports sytem, even as it is nowadays, in its present size 
is one of the reasons which make FreeBSD for me a unixish OS of choice.

An all packaging solution would be a major pain to maintain. I'm running 
Apache, PHP, Postgres etc. in my web server setups these days and there 
is no way I'd go to MySQL. There are just too many combinations of 
different "components" used in similar setups to make packages only 
solution feasible *without* limiting the choice the present system gives 
us in building the machines to suit our needs.

-Reko