On Tue, Sep 09, 2008 at 06:30:24PM -0700, Ed McKnight wrote:
> >>> 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 long as the packaging database knows about the services, then they'll
properly be removed on upgrade or removal. If the packaging database is
out of sync with the system -- they got removed from the database without
being removed from the system somehow, then there's no provision for doing
the removal anyway. The reverse scenario is more likely to happen though,
and is easier to deal with.
> >>>> 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.)
Yes, though the mechanism isn't as clear to me. I still have to look at
Bart's webrev for this feature, so I'm not sure how he plans to do the
removal. The issue is that if the fragment removal needs to be done prior
to package removal, then communication to the service what piece is missing
isn't as simple as just removing a file from the filesystem.
> >> 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.
Yes. If the image plan (the plan to take the install image from one
package state to another) indicates that a directory needs to be removed,
then it expects that directory to be empty. If it is not, it preserves the
contents, but moves them aside.
An exclusive directory would be one marked with an attribute promising that
anything in that directory is private to the package, so that when the
package is removed, the directory would be removed along with it,
regardless of whether it had any contents (and those contents would be
removed, rather than saved).
> 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)?
I'm curious about what kinds of files and directories you create in your
install scripts. Many instances I've seen of this could much more easily
have been done by putting them in the package directly (see virtualbox).
One potential answer is for you to deliver empty preserve=true files to
those locations and update the contents in the service.
> 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.
It depends on the behavior of the file. If it needs to survive reboots,
then an ephemeral directory obviously isn't appropriate, and there's some
other mechanism necessary for it. Like I said above, if you know where
it's going to go, just put it into the package and ensure it doesn't get
overwritten on upgrade.
> >>> 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?
As the provider of the config file, you'd provide the service to update it.
I'd recommend, however, that if you have configuration that multiple
packages need to deliver into, that a flat file is the wrong answer for
that. Either provide your feature with the ability to read fragments from
a directory, or put the configuration into SMF.
Obviously, this doesn't apply to software you don't write, or have no
influence over.
> >>> 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.
Are you delivering on OpenSolaris for November or April? If not, then it's
great to be ahead of the game, but careful not to get offsides. :)
> 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?
a) It's unlikely to happen by November. Beyond that, I'm not sure. We're
schedule-driven at this point, too. :(
b) File an rfe on defect.opensolaris.org.
> 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.
Right. See my comment above about this sort of situation. We may need to
invent (if Bart hasn't already) a means of communicating to the service
that the following components will be disappearing, and any pre-removal
actions should be taken. Post-remove is straightforward, pre-remove is
not.
> Thanks for your help and patience as we learn our way around this new
> world. --emk
And thanks for yours. There's a lot of mind-bending that's happening here,
and everyone involved in the process is learning and evolving, which ain't
easy, to say the least.
Thanks,
Danek
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
