Previously Manoj Srivastava wrote: > Actuall, maybe we should reconsider even that. The ast time I > updated apt, 2200+ packages were updated. Having them in a flat > folder is not likely to help browsing (heck, even a simple ls in > /usr/doc takes perceptible time). [pc135a;/usr/doc]-8> time ls > /dev/null 0.000u 0.010s 0:00.01 100.0% 0+0k 0+0io 93pf+0w (Okay, maybe not everyone has a pII on his desk. It'll probably be slower on my homesystem too) > I would much rather we assigned more structure to the set of > packages, and allow for a greater facility for grouping packages and > scoping common variables We could probably combine this with an effort to make looking for packages easier. > (all MUA's and News readers can then have a > mail-from variable in common, all news readers would share an NNTP > server address; but a news reader could have an over ride: so all but > one news readers read from the local spool, and one has an fast > minimalist off-site ews reader). I was thinking of adding a search order to implement that. So newsreaders could have a searchpath of "/news-reader:/strn" > To the point that this makes packages harder to find, I say > that a simple index (<package name>: Location set of lines in an > index file) would in fact be faster; we can invest in DB based index > files files if speed were an issue. Maybe add an item to the control-file which says where the package stores it's information? > I think that flat databases are not really scalable. This database is getting more and more complicated, although it should not be that hard to make a good fast implementation. We're bound to have some database-experts amongst us. Wichert. -- ============================================================================== This combination of bytes forms a message written to you by Wichert Akkerman. E-Mail: wakkerma@wi.LeidenUniv.nl WWW: http://www.wi.leidenuniv.nl/~wichert/
Attachment:
pgpT9pdimSfMi.pgp
Description: PGP signature