Danek Duvall wrote:
> On Fri, Aug 29, 2008 at 03:46:07PM -0600, Nicholas Solter wrote:
>
>> It looks like there are only three examples of preinstall scripts:
>>
>> Copy the meddb to a safe place
>
> Hm. We have an attribute for files that allows the package to specify they
> be preserved on installation, if they've been modified since the last
> installation. The functionality is similar to the renameold class-action
> script. Is that sufficient?
Danek,
Thanks for the information. I don't have the answers to your questions
at the moment, but someone from my team will get back to you after we've
investigated a bit more.
Thanks,
Nick
>
>> Delete a pre-existing SMF service (sccheckd/tcp,
>> rpc-100145_1/rpc_circuit_v, rpc-100533_1/rpc_circuit_v)
>>
>> Remove existing rsmrdt driver
>
> These two are for upgrading from a system where packages hadn't been
> removed properly?
>
>>> 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."
>
> The idea is that you'd deliver fragments of files -- take /etc/rpc as an
> example from your packages -- into a directory. There'd be an etcrpcbuild
> service already on the system (provided in a package you depended on), and
> you'd mark your /etc/rpc fragment as needing to restart that service after
> installation. That service would then go pick up your fragment and add it
> to /etc/rpc.
>
> The same idea can be applied to most of the files you talk about. The ones
> where this can't be done are the ones that are needed for boot.
>
>> Can you explain how this will solve the general-purpose problem of
>> cleaning up config files, temp files, and things like that?
>
> Temp files should be in temp directories. And probably removed by whatever
> created them. If you create a file at runtime, and the directory it's in
> is scheduled to be removed, then the entire directory will be "salvaged"
> and moved into a location in /var/pkg. I've toyed with the notion of an
> "exclusive" directory, meaning that if the directory is scheduled to be
> deleted, then it will be, regardless of the contents.
>
>> Disable metacld SMF serivice
>
> Removing the manifest for this service (which will be tagged with the
> manifest-update service) will do that.
>
>> Remove ${BASEDIR}/global/.devices/[EMAIL PROTECTED] directories
>
> This should be handled by the directory removal mentioned above.
>
>> Remove clhbsndr entries from ${BASEDIR}/etc/iu.ap file
>
> Don't have an answer for this yet. May be an addition to the driver
> action.
>
>> Delete a temp file /var/tmp/telemetry_backlog
>
> Yeah, if it's really a temporary file, it should go in an ephemeral
> directory like /tmp or /var/run, and if it's something that needs to stick
> around across boots, it should probably go into a directory you own.
> Otherwise, admins can clean it up at their leisure.
>
>> Remove entries for metamedd & metacld from /etc/rpc & /etc/inet/inet.con
>
> We'll want services for these files.
>
>> Remove clprivnet driver, Remove our changes to ${BASEDIR}/etc/devlink.tab,
>
> These will both be handled with the driver action.
>
>> 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,
>
> Not sure about these yet.
>
>> 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
>
> Services.
>
> Danek
> _______________________________________________
> pkg-discuss mailing list
> [email protected]
> http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
