On Sun, Jun 15, 2008 at 10:59 AM, Laszlo (Laca) Peter <Laszlo.Peter at sun.com> wrote: > On Sat, 2008-06-14 at 14:08 +0100, Peter Tribble wrote: >> On Fri, Jun 6, 2008 at 8:55 PM, Erwann Chenede <Erwann.Chenede at sun.com> >> wrote: >> > Hi All, >> > >> > As described by Laca in April [1] upgrading GNOME packages with IPS is >> > problematic as various caches need to be updated. >> > >> > Currently it is handled by postinstall scripts. As this functionality isn't >> > (intentionally) provided by IPS. The creation of SMF services to update >> > these >> > caches is needed. >> >> Looking at consequences like this make you realize just why you need some >> level of "scripting" integrated into packaging :-( >> >> Why 6 services? The number of services is exploding, leading to performance >> and >> manageability issues. Is there an intrinsic reason why these have to be >> separate >> rather than just a single 'update-caches' service? > > Well, they do very different things and should be triggered by the > installation of different kind of files. > > We considered a generic service, something like postrun, but decided > that letting smf manage the dependencies, etc is more robust and > having one service per cache makes it a lot easier to diagnose issues.
IMHO this sets a questionable precedent. Every package or package group that cannot do without postinstall will tend to supply it's own service. Do want to have a proliferation of postinstall handling services ? Wasn't the postrun service and future action identified for packages that simply cannot do without a postinstall ? Looks like the find commands will have negative impact on startup performance. The impact will be especially severe for Indiana LiveCD. A better approach would be to have some for of indication to the scripts that some schema/cache is dirty 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. > >> Why is the gdm login dependent on these services? Will gdm itself fail? > > I'm not sure all of these should really be dependencies of gdm, but > since gdm uses GNOME libs some of them definitely should be. > For example without pixbuf loaders, I doubt that gdm would be > able to start. The gconf settings may be needed for starting > accessibility at login. > >> Or will >> a gnome session just be degraded. If the latter, then for one you >> don't need to lock >> users of kde, wmaker, or twm, or whatever, out just because a bit of gnome >> failed; for another I would much rather have the system do its best >> and let me log in >> to fix it rather than just sulk. > > Right. We should be able to check for some of these features > in the gnome-session rather than in gdm, I think we should review > that. > >> In the same vein, what does failure of one of these services really >> mean? So something >> went wrong, somewhere. What went wrong? Does it actually stop anything >> working? > > Yes. GNOME will be pretty broken without some of these services. > Others will only slow it down. > [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. Regards, Moinak.
