Nicholas Solter wrote: > Bart Smaalders wrote: >> Nicholas Solter wrote: >>> Stephen Hahn wrote: >>>> * Nicholas Solter <[email protected]> [2008-11-25 20:39]: >>>>> Since we have to figure this out for clustering in the short term, >>>>> I guess we'll need a workaround. Since it sounds like the namespace >>>>> option you mentioned above isn't yet available, can you give some >>>>> more detail on the workarounds that are available now? Is there one >>>>> in particular that would be favored/recommended by the IPS team? >>>>> What do you think about Ed's proposal for a "removal metapackage?" >>>> For now, write an uninstall script and document it for your beta >>>> customers. Do not create a strange dependency graph, as escaping >>>> such >>>> a graph will be difficult. >>> Stephen, Bart, et. al. >>> >>> We've been working on this, and we're fine using install and >>> uninstall scripts to handle our postinstall and preremove scripting >>> needs. >>> >>> But this approach seems to break down with image-update. There >>> doesn't seem to be a hook to do our preremove/postinstall processing >>> during an image-update. >>> >>> Any suggestions? >> >> Perhaps we're not being clear. >> >> Software that relies on automated execution of scripts in installation >> or upgrade context will not work. > > Bart, > > Yes, we've noticed that ;-) > >> >> Software should plan on self-assembling after upgrade; any new software >> should be capable of reading old config. files and converting them. >> > > We can certainly do that, but it's more convoluted than doing it at the > package install time. I was just hoping that there was some sort of plan > for making this easier. I realize that IPS has a "no scripting" guiding > philosophy, but there are things like updating rbac, updating /etc/ > files, and so on, that are just easier to do right at package install time. >
Updating rbac will be done via packages delivering their rbac fragments; a service at boot will notice that things have changed and update the rbac files (details tbd). We need the system to manage its own config files whenever possible. IPS will do enough to get the system booted; the remainder needs to move into the components being upgraded, rather than some sort of out-of-band execution in install or upgrade context. We're working on getting everyone involved in changing their own config file handling in Nevada. - Bart -- Bart Smaalders Solaris Kernel Performance [email protected] http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
