[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