- - -
Another issue is repository cleanup once the service is removed. Rather
than do the clean up as part of package installation (or upgrade), I
think just release-noting is best. My rationale: cleanup as package
upgrade means something for this needs to live in packages from now on,
and the service is only in build 140, soon to be long forgotten as it's
just a development build. Another alternative is to put package cleanup
in and then take it out in a few builds; not sure this is worth doing
though...
I don't understand the problem here. Can you clarify the issue?
When a pkg image update is done, the service I'm removing files-wise
should also be removed from the SMF repository. If I don't it, SMF will
utter some messages that it couldn't run the service because it couldn't
find the files for it, and will drop the service to maintenance mode:
While Gnome covers this up, it is still stuff requiring cleanup...
In order to cover upgrades from build 140 to 140+, this repo cleanup
would have to be included in all versions of slim-install packages
henceforth, just in case someone upgraded from build 140 which contains
the service.
But we don't want to litter the packages with this cruft for a service
included in only one build. I thought it would be better leave the SMF
repository processing out of the packages and release note how the user
would do the SMF repo cleanup manually.
Alternatively, we could include the cleanup in the package temporarily
and then remove it in a build or two.
SMF should automatically remove any services whose manifests are
deleted. See 6859248. Why isn't that sufficient?
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
