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
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to