tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: smf manifests in pkgsrc



* On 2015-01-15 at 01:09 GMT, Paul B. Henson wrote:

> No further thoughts on this? I'm currently working on updating the
> openntpd package to the latest version, and as part of that plan to
> add an smf manifest for it. I'd really like to make the FRMI for
> that svc:/network/ntp:pkgsrc-openntpd so it can cleanly replace the
> bundled operating system service. As I described below, it seems
> that could be easily accomplished within the existing infrastructure
> simply by shuffling around where the substitution variables are in
> the manifest, but I feel I am missing something given your warning
> that changing the FMRI's would be a complicated process requiring
> code rewrite.

Whilst I can see the advantages in the /network/smtp case and a couple
of others, I still prefer to have everything under our svc:/pkgsrc
prefix to make it clear that these services come from outside the
platform and are not necessarily compatible with those provided by the
platform.  For me it greatly simplifies naming and identification,
especially where we provide services which don't have equivalents.

My point was that I'm happy for you to write a patch which allows you
to have your naming scheme whilst retaining mine.  Your initial patch
idea doesn't let me retain my preferred svc:/pkgsrc prefix.  Whilst we
do not recommend upgrades and prefer re-provisions, users may still
have configuration management scripts which modify pkgsrc SMF
attributes assuming the svc:/pkgsrc layout.

As for your postfix + syslog example, it isn't actually true that it
won't work - postfix will work fine as system-log is currently defined
as an optional dependency.  Yes this isn't technically correct, but we
ship postfix and rsyslog from pkgsrc by default in our images, and it
works fine.

If you can come up with a patch which lets us both have what we want
that'd be great, and I'd be happy to review and integrate it as
appropriate.  Ideally it would allow users to set FMRIs in mk.conf, so
you could add something like this to your mk.conf:

  SMF_FMRI.openntpd=	svc:/network/ntp:pkgsrc-openntpd
  SMF_FMRI.postfix=	svc:/network/smtp:pkgsrc-postfix

and it would get substituted everywhere necessary, otherwise it'd use
the defaults.

Making the SMF bits more user-configurable would definitely be a good
thing.

Cheers,

-- 
Jonathan Perkin  -  Joyent, Inc.  -  www.joyent.com


Home | Main Index | Thread Index | Old Index