OpenSolaris

When a pkgrm is performed in an alternate root environment, the pkgs SMF svcs are not removed from the SMF database.  See comments for more information...
Moving comments to description:

The same problem occurs when removing a package from a non-booted zone (scratch zone). See 6439553 for details.
*** (#2 of 9): 2006-06-22 14:14:12 PDT  xxxxx@xxxxx.com

bustos 2006-06-28

I think we need a deathrow file somewhere on the filesystem, to which
r.manifest can append a service name.  Then something like manifest-import
can delete the named services from the repository.
*** (#3 of 9): 2006-06-28 14:08:23 PDT  xxxxx@xxxxx.com

Generally, I agree -- though I was wondering whether the functionality should
be integrated with another mechanism (profiles?) longer term to avoid yet
another special-purpose mechanism.  For now, a comment in the file that it's
private and *will* go away in a near-term future release should be sufficient.

Implementation will need to do an inventory of the manifest and delete all
services (and all instances?) in the manifest, as there can be more than one,
even though the ON manifests don't take advantage of multiple services in
a manifest.

The other important part is to make sure that a "pkgrm; pkgadd" doesn't
delete the services on reboot.
*** (#4 of 9): 2006-06-28 14:18:39 PDT  xxxxx@xxxxx.com

bustos 2006-06-28

Indeed, it would be nice to integrate such functionality with enhanced
profiles, but it seems like that would take a shoehorn.  Profiles are about
modifying services, rather than deleting them.  I considered allowing
profiles to mask services, but that seems a bit out there.
*** (#5 of 9): 2006-06-28 14:30:29 PDT  xxxxx@xxxxx.com

sch notes that it may not always be safe to wait until manifest-import, when
services being deleted may already have tried to start.  Having deletion occur
before any services have started may be most appropriate, though may
require additional (planned, but not scoped) infrastructure.
*** (#6 of 9): 2006-06-28 15:18:28 PDT  xxxxx@xxxxx.com

bustos 2006-07-31

Note that this probably works to our benefit when packages are removed
and readded during upgrade.  A deathrow solution would have to be sure
not to break that.
*** (#7 of 9): 2006-07-31 10:28:30 PDT  xxxxx@xxxxx.com

In addition, we recently learned that the patches don't ever
explicitly run the appropriate class action script.  Thus, the final
proposal may need to be adapted for patching as well.
bustos 2007-05-15

Now it appears that the enhanced profiles project will allow profiles to
obscure services and instances.  Effecting service removal by adding
a profile will only accumulate cruft, though.  I think the best way to
solve this problem would be to enforce a strict correspondence between
package-delivered manifests and in-repository defaults.  We do this
loosely when manifests are installed or upgraded, but not when the are
removed, mostly because we don't know which services were in the deleted
manifests.  Enhanced profiles should add that information to the
repository, which should make this straightforward.  I fear that someone
will complain that this isn't backwards compatible, however.

bustos 2006-06-14

SVCCFG_REPOSITORY=$ROOT/etc/svc/repository.db svccfg delete service_fmri

Since the repository format is not committed, however, this may break
in the future.

N/A