Auto-configuring software -- potential problems

Bruce Jerrick root at ogcvax.UUCP
Thu Oct 4 08:03:33 AEST 1984


    There seems to be a trend toward interactive configuration and
installation of contributed software.  I think that unless this
is done carefully, there are going to be maintainability
problems.
    The problem is that some installation procedures
permanently and irrevokably alter the distribution.  Then, six
months later when someone says "I have a new version of XYZ, can you
install it here?", the question will arise (or at least, should
arise): "How does this differ from what we have, and which version
do we want?"  And of course this is complicated by local mods.
    Normally one can use something like RCS to retain the originals,
then make mods, and still be able to check out a completely original
version, to do, say, "diff -r ..." against a new version.
    Some auto-configuring distributions I have seen make it
difficult to keep virgin copies of the distribution; for example,
XYZ might "sed" its Makefile then copy it back onto itself.
It is also difficult to foresee what an auto-configure procedure
is going to alter, so one doesn't know what to save.

    So, I would like to suggest these guidelines, so that a
maintainer can get the distribution back to the same state in
which it was received:

1.  If the auto-configuration procedure modifies files, have it
    start with a template version of the file, or create it from
    scratch, rather than modifying the file in place.
    E.g., do this:

	sed ... Makefile.templ > Makefile

    or:

	Makefile.SH	(as in Larry Wall's trick "rn" distribution)

    instead of:

	sed ... Makefile > tmp
	cp tmp Makefile

   Doing it the first way allows one to make mods to Makefile.templ
   or Makefile.SH, which doesn't change by itself.  Otherwise, one
   has to make mods to a moving target.

2.  Have a "clean:" target in the Makefile that will get rid of
    files created in the auto-configuration procedure.  Doing
    a "make clean", then checking the original versions back out
    should get everything back to the state as it was when distributed.


    Intelligent comments are welcome --

        Bruce Jerrick
        Oregon Graduate Center
	(503) 645-1121 ex. 355
        CSNet:  bruce at Oregon-Grad
        UUCP:   ...tektronix!ogcvax!bruce
-- 
Bruce Jerrick
Oregon Graduate Center



More information about the Comp.unix.wizards mailing list