Michal Pryc wrote: > Hello, > > I would like to propose changes which will add new functionallity to the > IPS. Basically the changes will add new file/files on the server side, > which will contain specific meta data about fmri's. Other distributions > already have those kind of metadata[1] > > The file for Ubuntu gusy is around 1.3M gzipped and 6.3M uncompressed, > but the file contains much more information then we would put into > cataloginfo file and the file contains much more packages (5425). > I've made sample cataloginfo data and it's around 30K gzipped. > > Benefits: > - Package Manager/Update Manager startup with fully loaded > descriptions will be reduced. Our goal is to have fully > functional GUI application with loaded data in less then 10 > seconds. This needs to be done in the scalable way, so the user > will not loose the performance even with loads of authorities. > Every time I see this requirement brought, I have the same reaction. Under what conditions are we trying to solve this problem? I would guess (though I'm not certain) that if we set up a box with 24 processors, a terabyte of RAM, warmed the ZFS cache, and had a SSD disk on the backend, we'd have a shot at this today. On the other hand, if I give you a laptop running a single core 1.5 GHz processor, 512MB Ram (with some of that devoted to the video card), which has firefox running with 300 tabs, a rendering engine, and a 2400 RPM disk filled to capacity that's so taxed that typing has a frame rate, I don't think we'll be hitting 10 secs anytime soon. Of course, that's assuming a single repo roughly similar to p.o.o today. I can hand you a one package repo and I bet you'll start up in 10 secs or less. On the other hand, suppose the repo's got 1000 times as many packages as today, or 10000, or 1M? What are the parameters under which we're trying to meet this criteria?
These are questions I'd like answers for for the meeting BJ's mentioned if this 10 second startup, or any other timing, memory footprint, or disk footprint requirements are going to remain. > - client-server side operations will be reduced > - Ability to search for packages descriptions/names using web based > search. The fix for 3014 could be extended to allow users to > search for descriptions of the packages. > As far as I know, descriptions are already searchable via the web based search. > - The "pkg list -s" performance would be much improved > > When the cataloginfo file will be created/re-created: > The idea is that server will create/re-create cataloginfo file from > the meta-data: > - while sending packages to server > - pkg.depotd: > - add "--rebuild-cataloginfo" > Why wouldn't this be subsumed under rebuild-catalog? > Synchronization of the cataloginfo files: > pkg(1): > - the --refresh operation should allow to specify that we do > not want to get the cataloginfo file, by default we will > always get the cataloginfo file. > Why would I want a new catalog file but an old cataloginfo file (other than during testing)? > [snip] Brock _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
