Duncan wrote:
So I believe the cost to be quite reasonably managed, after all. Benchmarks would of course be needed to demonstrate that, but I believe it worth pursuing.
Agreed. Perhaps I'm just spoiled by RDBMS's at work or something, but it seems like we're trying to squeeze every ounce of speed out of a non-indexed flat file database and do everything we can to avoid actually putting all that metadata in something that actually is queryable no matter how lousy the final design ends up being.
Expressing the package database as a set of flat files works nicely - especially with cvs/git/etc. Actually working with that data directly on a real system doesn't make sense at all. Index it once and then only open the flat files on the rare occasion that you actually need to install one of them. Such an index can be centrally distributed, or it could be maintained as packages are rsynced (and of course users should be able to update it on demand as well).
When the speed of your package management system depends on the performance of find vs grep -r, you are doing something wrong. Neither works all that well.
