I had originally assumed the cache would be generated during the *build* of the oscar packages for each supported distribution. If additional RPMs are present, e.g., via an update of the original CD, then the --cache=update would be quite quick.
Also, don't forget, on a real system, even my laptop, it's only a few minutes to build the complete cache from scratch.
So one of the features desired was the ability to very efficiently update an existing cache that was already "mostly" representative of the rpms found. I think you mentioned that you had this implemented...
If so, then it would allow certain optimization by providing a "seeder cache" to begin with, which I would highly recommend doing per supported distro anyway. It saves that much time per installation... totally worth it.
Jeremy
-- David N. Lombard My comments represent my opinions, not those of Intel Corporation.
------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56&alloc_id438&opick _______________________________________________ Oscar-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/oscar-devel
------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Oscar-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/oscar-devel
