The startup time for the wizard, from ./install_cluster to the point the wizard is running is about 36 minutes on the VMWare box I'm testing with. This needs to be changed if testing is to occur. I have a couple suggestions on how to fix some of the slowness.
Wow. That's harsh. How long does it take on subsequent runs? It seems like there should be a way to optimize the whole process anyway. We do many operations in a "brute force" manner to make sure it gets done. In many instances, if nothing has changed, running the oscar_wizard directly out of the scripts directory actually works just fine, and takes a second to launch. Granted, no checks are made to see if a new package has been unpacked, some config.xml changed, or if a necessary perl rpm has been removed or something. But there has got to be a far more efficient way of checking than we do right now. This will gain importance as we expand the oscar wizard further into the day to day maintenance realm.
1) update-rpms takes a long time to build its cache. That's fine, but let's do that earlier and use it to install the other rpms later.
2) on a related note, we need to integrate depman/packman into the current packagebest rpm installation mechanism. I'm pretty sure that means linking packagebest functions to their analogues in packman. Matt... is there any way this can happen soon? This will allow us to be testing depman/packman while testing OSCAR and would allow for many simplifications in other areas of the OSCAR infrastructure.
I thought this was part of "integrating" pacman/depman in the first place and thus had been done. Wasn't this the plan all along?
3) Reduce the amount of debug info spewed to the terminal. Some is useful, but some should be hidden behind a --debug flag. All of us who write scripts that run at startup should evaluate what information is "need-to-know" and what is "might-want-to-know".
I totally agree here. It would be nice if we could have the console output variable as Jason suggests, but always have a verbose log file. (right now, I believe it's just a tee so they're fixed to be the same)
Jeremy
I think that by replacing packagebest with depman/packman, the startup time will be cut in half, since we'll only be building one package info cache.
Thanks, Jason
------------------------------------------------------- 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
------------------------------------------------------- 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
