Danek Duvall wrote: > I'd be curious to see what your preinstall use cases are.
Danek, Thanks for your help. The following page lists all the current system V packaging script functionality in the cluster packages: http://www.genunix.org/wiki/index.php/IPS_Conversion It looks like there are only three examples of preinstall scripts: Copy the meddb to a safe place Delete a pre-existing SMF service (sccheckd/tcp, rpc-100145_1/rpc_circuit_v, rpc-100533_1/rpc_circuit_v) Remove existing rsmrdt driver > > As for pre-remove, Jordan pinged me about this just earlier today. I'm not > sure if this is part of Bart's restart_fmri wad, but the idea is that the > fmri tagging that wad introduces will also be used to disable services > before uninstallation of its components, and re-enable it afterwards, at > which point it can notice that components have been removed, and unregister > them. > Can you say a bit more about this? I'm not sure what you mean by a service's "components." Also, it sounds like the service in question would need to be one that's not installed by the package being removed, if it's going to do something after the package is uninstalled. Or maybe I'm just not understanding this proposal. Can you explain how this will solve the general-purpose problem of cleaning up config files, temp files, and things like that? To make this a bit more concrete, here are some examples of preremove functionality, from the page listed above: Disable metacld SMF serivice Remove ${BASEDIR}/global/.devices/[EMAIL PROTECTED] directories Remove clhbsndr entries from ${BASEDIR}/etc/iu.ap file Delete a temp file /var/tmp/telemetry_backlog Also, I know we weren't discussing postremove yet, but here are some example of postremove: Remove entries for metamedd & metacld from /etc/rpc & /etc/inet/inet.con Remove clprivnet driver, Remove our changes to ${BASEDIR}/etc/devlink.tab, Remove our changes to ${BASEDIR}/kernel/drv/sd.conf, Remove our changes to ${BASEDIR}/kernel/drv/ssd.conf, Remove our changes to ${BASEDIR}/etc/system, Remove our changes to ${BASEDIR}/etc/iu.ap, Remove our changes to ${BASEDIR}/kernel/drv/log.conf, Remove our changes to ${BASEDIR}/var/spool/cron/crontabs/root, Remove our changes to ${BASEDIR}/etc/inetd.conf, Remove our changes to ${BASEDIR}/etc/rpc, Remove our changes to ${BASEDIR}/etc/services > A removal veto would require that it know at disable time what was going to > be removed, and I'm pretty sure that's not done in Bart's current wad. I'm > also not sure what the service would do to exercise the veto. > > But what would the grounds be for a veto, anyway? It's not clear to me how > that would actually be useful. I think the idea is that we'd either need a way for the package installation itself to take care of the above preremove/postremove functionality, or to provide a way to prevent the uninstallation of the packages until the user had run some sort of unconfiguration script or other system management tool to clean up properly. Thanks, Nick _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
