On Sunday 13 May 2007 11:37:57 Peter Jeremy wrote: > > The options I can see are: > - Ignore the existence of INDEX - which makes computing dependencies > very time consuming > - Fully rebuild INDEX via "make describe" whenever you update any ports > - this takes of the order of an hour > - Find and rebuild the changed bits of INDEX - p5-FreeBSD-Portindex > uses this approach. > - Build a tool that functionally does "make describe" but does it in > bulk much faster (eg by pre-parsing the include files once instead > of 17000 times). >
Having played around with using Postgres as a database for ports - I must stress that its not a database vs. flatfile issue - It is quite easy to build a reasonable "Ports database" - however it does not help on the issue - namely that dependencies and options means that it is needed to run make in order to gurantee that the INDEX file are correct It seems to be a non-debate what format the database is in if there not a good answer to how ensure that only ports that has changed are updated. At the end of the day - "make based ports" are the only real safe way to manage ports - However the focus on the indexing side seems misplaced - example - make INDEX on this host take 8-12 Minutes - compiling all ports installed takes 24 Hours - now if I "hand build" the dependencies structure and run the builds in parallel it takes down to 4-5 Hours - so lets say we half the time it takes to maintain the index - well - it cuts minimum time off the entire build process and the effort and energy proberly better spend on trying to define a build sequence that allows ports to build with "make -j x" and with parallel builds where "-j n" does not work Using XML for INDEX are a very good idea mainly because it allows "ports" to interface in an easy way to external tools - e.g. java frontends - web browsers etc, etc. However there are drawbacks - Yet I feel that the discussion about what tool to use as indexing are completely misplaced if the only point is that somebody likes SQL better than a directory tree. > >Yes, and i don't buy the idea that using *existing* tools is better than > >using the best tool for the job (assuming one can prove what is the best > >tool, > >considering power, familiarity, etc.). > Remind me - we are told that SQL are the answer but what was the question again? > Demonstrate a better tool. > Always the best way ;-) _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
