On Mon, Jun 16, 2008 at 2:33 AM, Erwann Chenede <Erwann.Chenede at sun.com> wrote: > Hi Moinak, > [...] >> >> Looks like the find commands will have negative impact on startup >> performance. The impact will be especially severe for Indiana LiveCD. >> > > Afaik the LiveCD takes an image of the file system so these services don't > need to be present on the LiveCD also > during the construction of the LiveCD one controls what's on the LiveCD so > the caches can be generated statically > before hand by the distro constructor I believe.
In which case the GDM dependency should be optional to allow GDM to come up if these services are disabled/not present. >> >> A better approach would be to have some for of indication to the scripts >> that some schema/cache is dirty > > IPS actions when available could do that. Once it is available we'll be able > to make these services more clever. >> >> and the update needs to be run rather >> than blindly doing finds. > > [...] >> >> Better still would be to have the services disabled >> by default and dependency from GDM being optional_all. A refresh of the >> GNOME packages should trigger the services to execute and disable >> themselves upon successful completion. >> > > Yes this is an interesting idea but without IPS actions I don't see how to > achieve this. >> >> [OT] Can't help but mention that this is a bigger GNOME problem that it >> needs so much of postinstall processing. I had packaged complete KDE >> 3.5.x for BeleniX and not a single package required any kind of >> scripting. >> > > Hmm, interesting, howdid KDE go around this problem of updating caches that > span multiple packages without > post install scripting ? Is this done at application startup ? KDE maintains the sycoca (System Config Cache) dynamically via a daemon that is started when you login to the desktop or start any KDE application when the desktop is not running. The daemon takes care of efficiently maintaining the cache without need for scripting support. In addition all config queries are satisfied from the cache DB as opposed to the individual file-backed gconfd. These actions should ideally be handled automatically by gconfd instead of relying on external scripting. Regards, Moinak. > > Thanks, > > Erwann > > -- > Erwann Ch?ned?, > Desktop Group, Sun Microsystems, Grenoble > > >
