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. > 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. > If something does go wrong, should more effort be expended on trying > to work out why? > > If a service fails, how does the user know how to fix it? Same as other services, I guess... > If one of these services is rerun after and then fails, going into > maintenance, > will it kill the graphical login? Don't think so. > How does an administrator know that it isn't safe to disable these services? If they don't use GNOME at all. > (Particularly if they're running a system that doesn't have a > graphical login, so > they wouldn't get alerted by the gdm dependency, but potentially all gnome > applications might be broken.) That's a good point, but I can't think of a better way to express GNOME's dependency on these services. Laca > Looking at the scripts: > > Why find -print? Is -print necessary? > > Why find -follow? This just seems wrong to me, as why would you not know > where the files really are anyway, and you run the risk of following > a misplaced > symlink into a black hole. And you're not consistent with whether -follow is > used or not. >
