Hi Danek,
(Now have you marked for text-only...)
Sorry for the delay; see inline...
Nicholas Solter wrote:
> 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?
>>
Yes.
>
> 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.
>
Here we go...
> 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?
>>
Or upgrading to a new version, or simply removing the product or
optional component.
>>
>>>> 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.
>>
Your paragraph above talks about installation; is it safe to assume that
unistall would do the reverse? (More on pre-remove at the end.)
>> 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
>>
Please elaborate here: you mention removal "by whatever created them,"
then, "will be 'salvaged'" which phrasing sounds like it's being
performed by ips itself. Presently we (the creator) remove files and
directories in pre- or post-install, so this is exactly the topic: how
do we get to remove them under IPS (i.e. post-remove)? And please say
more about the salvage and exclusive directory thing.
>> "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.
>>
We presently remove it explicitly in pre- or post-remove. Is the
principle now to relocate tmp files and directories to /tmp or /var/run
and just not delete them at uninstall time? If the tmp files are of no
use to the admin why would we ever want to leave them around? Requiring
manual clean up in the future, when it wasn't required in the past,
seems value-minus.
>>
>>> Remove entries for metamedd & metacld from /etc/rpc &
/etc/inet/inet.con
>>>
>> We'll want services for these files.
>>
How scalable is this approach of providing services for adding and
removing entries from files not owned exclusively by the product in
question? If we turn out to be the first product to add/remove entries
to/from the not-yet-announced Solaris config file /etc/foo/bar.conf do
we need a delivery of a new service from IPS?
>>
>>> 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.
>>
We're actually being driven to a schedule to convert to IPS packaging.
Managers asking questions, and all that sort of thing. What kind of
answers can we go back with about (a) when decisions on the above might
be made and the functionality implemented and (b) what the general
process is when we find ourselves with another case not already handled
by IPS services?
>>
>>> 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.
>>
A previous question, not raised in this particular thread, was about
pre-remove and taking actions prior to removing the bits themselves. One
concrete example would be the removal of an optional component of ours,
our gui management application. At install time the app registers itself
with the Common Agent Container (cacao) and with the Common Console
(Lockhart). In these cases registration means both delivery of certain
files to certain locations *then* invocation of certain cacaoadm and
wcadmin commands. First we put down the bits, then we do an action. The
SMF approach should work for install time. At removal time we need to do
the opposite: use cacaoadm & wcadmin to tell those subsystems we're not
staying, *then* we remove the bits.
There was some conversation on a different thread where it seemed that
people didn't think it mattered if we unregister before removing the
bits, or after. I think it matters. We need to get clear on if there's
an uninstall smf action (or other hook) that will let us run a service
or stop a service or otherwise get a hook from which we can call unreg
methods on things like cacao *before* the bits are removed. I'm not
particularly SMF-literate so it may be that your answer above about
Bart's work is sufficient, and I've simply been confused by the talk of
post-remove unreg versus pre-remove unreg.
Thanks for your help and patience as we learn our way around this new
world. --emk
>> 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
>
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
