[csw-devel] [csw-maintainers] dynamically generated adm scripts

[Ben Walton]

Excerpts from Philip Brown's message of Mon Feb 09 17:31:42 -0500 2009:
> > > echo I'm the postinstall script for $(GARNAME) v$(GARVERSION).
> > >
> > > for i in /tmp/*; do
> > >    echo Found $$i in /tmp;
> > > done
> > > endef
> 
> Errr... this sort of usage disturbs me. 

[Assumes you're not commenting specifically on the dumb example used to
show variable escaping and a general overview...]

The use that brought this to my mind was the docbook and xsl stuff
where (since I was templating from rhel) I used version numbers in
directory names.  To make the script easier to maintain, I turned
paths including the version info into paths with variables in them.
This leads to a case of script modification every time a version
changes.

> My programmers intuition suggests that the first thing to be done, would be
> to have a maintainers-public review of that script.

The script is 'fine.'  By it's nature, it's a long stream of
registration statements .  It could be turned into a few loops (I
didn't since I wanted it out so I could build off of it), but that
wouldn't alleviate the need to twiddle it each time.  It doesn't
'need' to use this functionality, but doing so will lessen (not
eliminate) maintenance requirements.  It's in svn (public) already if
you care.

If you want to say that version numbers shouldn't be in path names and
make that a CSW convention (maybe it already is?) that's fine.  It
would (in this case) remove the need for this type of 'macro'
expansion.  This is common elsewhere though (see rpm).

> If the script can be rewritten in a cleaner fashion, then this "other
> method" of doing things, may be completely unneccessary.

There are ways to avoid needing this functionality.  Many scripts
would never need it.  That doesn't mean that it doesn't have uses
though.  You'll note that rpm provides a built-in macro language that
is used for this type of task quite regularly.  That may be, in part,
due to the directory structure that rhel uses (where version numbers
are frequently used in paths), but regardless, there are cases where
this can be a handy thing.

Thanks
-Ben
-- 
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302

GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.opencsw.org/pipermail/devel/attachments/20090209/f1e843f1/attachment-0002.asc>