[csw-maintainers] cswclassutils: location of template init scripts
Philip Brown
phil at bolthole.com
Tue Jun 1 21:14:17 CEST 2010
On Tue, Jun 1, 2010 at 11:16 AM, Maciej (Matchek) Blizinski
<maciej at opencsw.org> wrote:
>
> In any case, I've submitted the cups package with the init script in
> /etc/opt/csw/init.d, until we figure how do to it better.
>
> I've removed the initfile-wrong-location check from checkpkg. I'm
> thinking of putting in a check that throws a message for cswinitsmf
> class files under /opt - we now know that it guarantees a broken
> package. What do you think?
I think we should use "cups needs an update" as motivation for "lets
figure out how to do it best,then fix cups to use it".
My thoughts on potential fixes so far are two fold.
either:
a) We partially revert to prior behaviour: we say that init scripts
should be declared in the template
as in /etc/opt/init.d/foo... but that the class action script will and
must copy it to /opt/csw/init.d/foo if not already there.
or
b) we figure out a way to have the class action script always call
itself "appropriately" somehow.
Which we COULD technically do. If we define the new actions as:
"init scripts always go in /opt/csw/etc/init.d/$PKGINST".
Then the class action script, when called, copies files given on stdin
in normal behaviour...
(and ignores, if destination target already there)
but then after that, ignores the list, and does its usual processin on
"all files in /opt/csw/etc/init.d/$PKGINST".
This second approach would have one very definite advantage, in that
we would then no longer have to write a separate script for the case
of,
"Hey, I just copied over (or NFS mounted, or whatever) /opt/csw to a
bare machine... how do I get
any init scripts taken care of?)"
You just run the CAS with PKGINST set, and it Does The Right Thing.
and/or it would be trivial to provide a utility wrapper consisting of
#!/bin/sh
cd /opt/csw/etc/init.d
for p in CSW* ; do PKGINST=$p /usr/sadm/install/scripts/i.cswinitsmf ; done
The drawback, would be in converting existing packages that use the
old style, to the new style.
Would be nice to have some sort of middle ground somehow...
More information about the maintainers
mailing list