[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
RE: smf manifests in pkgsrc
> 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…
Main Index |
Thread Index |