I will describe here the way urpmi, the mandrake tool is doing it. I thing we should provide a compatible system.
1) a cache is generated in each sources (for instance CD1, CD2, local repository, distant respository). Let's call this the cache file for the packages. For instance, each CD has it's own cache file in it, each mirror. Local repositories are scanned once and the cache is generated once. If I want to add RPM then I have to update the cache for this source. It can be long depending on the number of RPMs in the directory. 2) when a source is added, then the cache file is downloaded/loaded (if on the local disk) and the global cache for URPMI is rebuild with this new information (a few seconds). 3) when I use a urpmi command, the global URPMI cache (that integrate the information from all the sources) is queried. In our case, I think that we should separate the distro RPM from the others RPM in the /tftpboot/rpm directory so that The cache for distribution is generated once (it can even be pregenerated and avalaible inside OSCAR or on any web-site!). The server RPM and client RPM sources are generated each time the wizard run after the RPM have been copied in the /tftpboot/rpm/XXX/ directory. As there is not many RPM inside the oscar tarball (128 in the actual OSCAR packages, less than that because some RPMs are duplicated because of mdk/redhat incompatibilities) the generation of those files will be very fast... Ben and my $.01 * Jeremy Enos <[EMAIL PROTECTED]> [04-02-27 14:17]: > At 11:37 AM 2/27/2004, Jason Brechin wrote: > >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 -- Benoit des Ligneris Ph. D. <|> http://benoit.des.ligneris.net/ Centre de Calcul Scientifique <|> http://ccs.USherbrooke.ca/ OSCAR Developpe(u)r <|> http://oscar.sourceforge.net/ �duLinux <|> http://www.edulinux.org/ R�volution Linux <|> http://www.revolutionlinux.com/ ------------------------------------------------------- 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
