Hi Danek. See inline...
Danek Duvall wrote:
> 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.
>
To restate: smf services and drivers can be stopped/removed in an
orderly manner under the currently planned set of actions. The smf
action is not yet available for install or uninstall. (Correct? Dates?)
Does the driver action work correctly under uninstall today? Any
significant bugs against driver install?
>>>>>> 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.
>
I agree that frag removal from system config files can generally be done
'post-remove'. One outdated counter example would be /etc/inetd.conf.
The model there is remove your line(s); cause inetd to reread that file
such that that your bits can't be invoked anymore, then finally remove
the bits. Not sure we have a current example of this model, but IMHO
it's very worth considering...
Depending on how you generalize the problem/solution, the solution for
the "pre-remove unregister" conundrum (see below) could satisfy this
case, too.
>>>> 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).
>
I think others have already commented on this point. I'm not talking
about creating files & dirs at install time (though we have had to copy
files from one dir into another in the past and in at least one
unfortunate case I can think of, still need to) but am talking about
removing dirs and files created by the app during its lifetime. It
sounds like the exclusive attribute would meet our needs marvelously.
You said you've "toyed with the notion" so it's probably not on a
schedule anywhere yet. I'll add this feature to our dependency list and
you can regret mentioning it :)
> 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.
>
Yup. In my hypothetical example above, Solaris provides the config file.
It sounds like this model would push all the way back into their project
requirements such that they would have to write an updating/de-updating
service and deliver it to the world in advance of when there might be a
consumer of it.
>>>>> 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. :)
I think Nick already mentioned that we're to deliver with 2009-04, but
of course feature freeze is well before that and we need to have all our
stuff working reasonably before FF.
>
>> 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. :(
Is the schedule published and available to read?
>
> 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.
>
Agreed. Please keep us posted about this type of pre-remove hook. I'll
need to add it to our list of dependencies. I think that list flows up
to OpenSolaris Cabinet.
thx, --emk
>> 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
