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

Philip Brown phil at bolthole.com
Fri Jun 11 18:22:15 CEST 2010


On Fri, Jun 11, 2010 at 6:38 AM, Maciej (Matchek) Blizinski
<maciej at opencsw.org> wrote:
>
>> So it seems the main question is how to handle our "legacy"
>> /etc/opt/csw/init.d packages, without having to force rebuild of quite
>> a few.
>
> Adding a duplicate in /opt/csw/etc/cswinitsmf would avoid those problems.


yup. i just think we would be better off automating the duplication, via CAS



>> I had an "interesting" thought: svr4 hackery ;-)
>>
>> Perhaps we can have the CAS script, dynamically RELOCATE, rather than
>> copy, init scripts from /etc/opt/csw/init.d, to /opt/csw/etc/[...]
>>
>> By judicious use of  removef, rm, and installf, I think this may be possible.
>>
>> Then, packages deployed after the new CSW installation, woudl have a
>> uniform install location, even if the package itself was pre-standard.
>
> Can you tell more about this idea? What kind of code would handle
> that?  (A shell script? Where would it be?)

The CAS.

pseudo-code:

[start of read filename from stdin loop]
case $filename in
    /etc/opt/csw/init.d/*)
        NEWfilename=/opt/csw/init.d/cswinitsmf/$PKGINST/`basename $filename`
        cp $filename $NEWfilename
        installf $NEWfilename
        removef $filename   # not sure this will be allowed though ;-)
        filename=$NEWfilename
   ;;
esac

   ## now proceed to do "normal" init processing on $filename, either way.

## Of course, the above would have to be tweaked for chroot, blah blah blah.
## If the removef is disallowed, above.. .then we simply "ignore"
files under /etc/opt/csw
## when it comes to remove time. we presume that they get handled by
their automatically
## duplicated copy in /opt/csw/init.d ?  IF /opt/csw/init.d/cswinitsmf
exists, that is.
## That handles the case of legacy installs done before newer version
of cswinitsmf installed.

> In any case, I'm weary of throwing away or significantly modifying
> what we have right now, just because of the NFS case.  I'd rather add
> whatever NFS setup needs, without disturbing the existing solution.
>

I believe the above proposal meets that criteria. The only
"significant modification" is a one-time alteration of the cswinitsmf
CAS package.


More information about the maintainers mailing list