Minor correction inline...
Ed McKnight wrote:
> 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
in pre- or post-*remove*
> 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
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
