On 2007-May-12 23:44:22 +0200, Michel Talon <[EMAIL PROTECTED]> wrote: >Really i don't think at all this way. I think that *perhaps* SQLite >may marginally better than a Berkeley database for solving part of the >problem, not much more. What i reacted to, was the conservatism which >pervades the community as soon as someone emits the idea of using a new tool.
So far, the proposal has basically been "SQLite will solve all your problems". Similar magic bullets have been offered in the past and either fail to eventuate or fail to work as promised. If someone were to come up with a concrete proposal and a prototype (possibly in collaboration with one of the SoC people) that actually demonstrated some of the claims then I'm sure you will receive a warmer welcome. >To answer the slowness problem in registering installed packages, one may >think about making use of the INDEX file. In fact all the information that >is necessary to fill the dependency entries is contained in INDEX, and >accessible here in milliseconds with any tool such as awk. The problem is that the master reference for port names and dependency information is the port Makefile. It is very difficult to see how to change this arrangement without causing unaccepable upheaval. Parsing and searching INDEX is very fast but creating it requires running 17000 "make describe"s - which is very slow. You can view INDEX as a cache but working out when (and where) it is out of date is extremely difficult (eg changing a flag in /etc/make.conf can affect the INDEX). 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). >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.). Demonstrate a better tool. -- Peter Jeremy
pgpy0PFUTL4bF.pgp
Description: PGP signature
