[csw-maintainers] cswclassutils: location of template init scripts

[Maciej (Matchek) Blizinski]

No dia 9 de Junho de 2010 19:16, Philip Brown <phil at bolthole.com> escreveu:
> you would never "install a package" on one of these nfs client
> machines. the empty input case is to solve two use cases.
>
> 1. when it gets automatically called in a zone, from a global pkgadd,
> when the maintainer specified a file in the class under /opt/csw
>
> 2. to allow the script to be called directly, by the admins of those
> nfs client machines, to "do the right thing" for demon setup on the
> clients.

I see; the init file under /opt/csw is there for the NFS client machines.

There's also the argument that you don't need to vary the init script
between the zones, but it's not a strong one.  The absence of the init
file from /opt is a show stopper for an NFS setup; in the sparse zones
scenario it doesn't pose any practical problem at all.

I think that handling SMF via straightforward CAS is a simple an
elegant solution, and it works well with the current file layout.  The
main point of the elegance being the 1:1 correspondence between the
init files and CAS executions.  Losing it would be a significant cost
from the SMF handling point of view, if you think about debugging
situations for instance.

IIUC, the main problem with the NFS setup is the absence of the init
script from /opt.  If so, why not include one more copy of the init
file under /opt/csw/etc/cswinitsmf/$PKGINST so that it can be used by
admins of an NFS client system?

I know that the counterargument is the duplication of data; but it's
not much of a practical problem.  If you worry about users not knowing
which init file is used, you can add a README file in the
/opt/csw/etc/cswinitsmf directory, saying that these are only for the
shared NFS purposes and the main location is /etc/opt/csw/init.d.

In this way, NFS admins would have a script to run, and all the
packages using init scripts could just carry on with their lives.

Maciej