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]"
