On 05/20/10 07:50 AM, Dave Miner wrote:
On 05/19/10 06:24 PM, Jack Schwartz wrote:
On 05/19/10 02:30 PM, Dave Miner wrote:
- - -
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?
This doesn't seem to work. Maybe I did something incorrect? Here's
what I tried:
- I had a b134 live CD image, so I installed from it.
- I manually copied the live-var-pkg-move.xml service bundle to
/var/svc/manifest/system
- manually copied live-var-pkg-move script to /lib/svc/method.
- svccfg import live-var-pkg-move.xml
- verified via svcs that the new service existed and was online.
(Actually I had to fix permissions on the script and iterate again
before the service went online.)
- deleted the two files
- rebooted: I saw the svcs errors I reported.
- pkg image-update to B136 from a private repo. this build didn't have
the service.
- rebooted: I saw the same svcs errors again
- rebooted again: I saw the same errors again.
I'm not sure why you chose this path to test things rather than just
test a built image, but your assumptions here seem flawed.
SUNWslim-utils is removed from the installed image, and the SMF
repository is reset to the seed (review install-finish and the ict
modules if you need to verify this yourself), so that all services are
explicitly re-imported on first boot.
OK. That should do it.
Thus I don't see how your service would ever appear in the installed
image. But if you are going to test this path, then use "svcadm
restart manifest-import" to import your manifest initially so that you
are reproducing what actually would happen if that manifest somehow
ended up on the installed system and if there are bugs then file them
with SMF.
OK. Yes, I was confused... Bottom line is that live images are
disjoint from each other. If in the future I produce a live image that
doesn't contain my service, there shouldn't be anything new to remove,
regardless of current live image contents.
Thanks for your help.
Thanks,
Jack
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
