Re: smf and rc.d

[Jonathan Perkin <jperkin%joyent.com@localhost>]

* On 2015-09-19 at 21:52 BST, Richard PALO wrote:

> Le 19/09/15 22:03, Jonathan Perkin a écrit :
> > * On 2015-09-19 at 15:22 BST, Richard PALO wrote:
> > 
> >> At "real" install time, INIT_SYSTEM should determine whether to
> >> install the packages rc.d files to RCD_SCRIPTS_DIR or to install the
> >> smf file. I believe share/examples should always have both.
> > 
> > I don't see any merit in that.  It would add significant complexity,
> > and be very fragile having to determine INIT_SYSTEM at install time.
> > Where would you set it, pkg_install.conf?  Environment variable?
> 
> In mk.conf as usual.  By default it is, on SunOS, INIT_SYSTEM?= smf.
> No different then things like X11_TYPE, BDB_DEFAULT or PSQL_VERSION_DEFAULT etc.

mk.conf isn't parsed at install time.  None of the variables you
mention are install-time settings.  In fact there are very very few
variables that are consulted at install time, and they are mostly for
specific enabling/disabling of commands (e.g. PKG_SKIP_SMF), certainly
nothing as complex as deciding which init system to configure.

> > Also, why would you want rc.d scripts when you have SMF support?  And
> > what happens when we introduce launchd/systemd/etc support, do all
> > those INIT_SYSTEM's get installed too even though they may be
> > completely incompatible with the target system?
>
> missing SMF support?  good example... as a test, setting
> INIT_SYSTEM=rc.d in cups-filters permits a successful packaging.

If INIT_SYSTEM=smf means cups-filters doesn't package then that's
simply a bug in that package.  Looking at the bulk build reports and
the package, it seems that all we need to do is only enable the
"--with-rcdir" configure argument when INIT_SYSTEM is rc.d.

Grepping through the report shows that this is the only failure due to
rc.d PLIST errors.

> Also, they are installed in examples, for just that reason. If
> perhaps not directly useable, at least the basis is there for
> tailoring to local needs.

It's not just the examples, setting INIT_SYSTEM=rc.d adds a lot of
pkginstall complexity to handle the scripts correctly, and you would
need to rewrite all of that support, as well as the SMF install and
deinstall scripts, to only enable those code sections based on
INIT_SYSTEM.  Instead of a package only including INSTALL script
sections for the target INIT_SYSTEM, they will now include scripts for
all systems, regardless of whether the user wanted them or not or
whether appropriate for the target system or not.

> Good point as to the other INIT_SYSTEMs... does this mean that these are
> now pkgsrc variants, as binaries no longer globally work 
> (although it is only the copied init system file that is different). 
> seems perhaps like a step in the wrong direction...

Not sure what you mean here.

> > Basically I see no advantage to doing it that way and plenty of
> > drawbacks and inconsistencies.
>
> okay, perhaps, but there is an anomaly to be worked out at present.

What anomaly do you mean?  I guess this is the main issue here, for us
the SMF support works great but perhaps you are having issues with it,
or do you only mean the cups-filters bug?

Cheers,

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