On Sun, 2008-06-15 at 14:02 +0530, Moinak Ghosh wrote: > > 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 ?
That's the advice we got in previous discussions of the subject. > Wasn't the postrun service and future action identified for packages that > simply cannot do without a postinstall ? A possible postrun-like implementation of these services would be to place scripts in a directory and postrun would execute scripts newer than the last time it run. Note that this basically enables arbitrary scripting to be included in the packages, except it would be postrun (started via smf) that executes the scripts and not the package system itself. You can consider this a + or a - depending on your position on package scripting... However, you would not be able to express SMF dependencies on these scripts, only on postrun itself but that's not very useful. So how do you know if, say, gdm is ready to start? That's why we decided that individual services are a better option. > Looks like the find commands will have negative impact on startup > performance. The impact will be especially severe for Indiana > LiveCD. Right. On my laptop, these services together take < 1sec when they have nothing to do, but they would obviously take longer on the live cd. They need not run on the live CD, though. We could run the services during the image build and disable them on the live cd. > 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. The problem is that there are other ways than pkg install that can invalidate the caches. pkgadd is still supported, custom installer and also possible and horribile dictu, someone can run make install as root... Laca _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
