RE: smf manifests in pkgsrc

["Paul B. Henson" <henson%acm.org@localhost>]

> From: Filip Hajny [mailto:filip%joyent.com@localhost]
> Sent: Thursday, January 15, 2015 1:49 AM
>
> but the tooling didn’t feel right. There’s very little (if anything) that you can re-
> use in a SMF service if methods, properties etc. differ too much for each
> instance, and once you import a new instance into an existing service, it’s never
> the same thing anymore.

Hmm, I'm not completely clear what you mean. As you said, SMF documentation, at least at such a technical level, isn't very available :). You are saying if I create a completely separate manifest for svc:/network/ntp:openntpd, and load that onto the system, it impacts the existing svc:/network/ntp:default service defined in a different manifest to the point where even if I do a svccfg delete svc:/network/ntp:openntpd, the original svc:/network/ntp:default is somehow permanently different?

> just because we have thousands of customers and users relying on this.  Maybe
> differentiate between SunOS flavors in smf.mk and provide a “Solaris integration
> style” mode there?

I don't think there are that many packages which overlap with native OS instances? Jonathan mentioned a more generic mechanism of just being able to arbitrarily override an FMRI on a per package basis, that would possibly be useful even in other contexts and might be a better way to go…