[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Some implications when separating code and parameters



If you modify scripts in /etc/init.d/ or /etc/cron.* to suit your needs
then "dpkg" moans next time you upgrade. Usally you only want to change
some numbers in those scripts - the most prominent example is
/etc/init.d/network.

There is a solution to this problem which is one issue discussed in
"debian-admintool": separating parameters from code. Let me give a short
example:

        #! /bin/sh --
        # /etc/cron.daily/news - CRON script to purge files in /var/news
        # after 30 days.

        /usr/bin/news -e 30 -x WELCOME,POLICY,NEWUSERS

Using variables instead of fixed parameters improves the situation:

        #! /bin/sh --
        # /etc/cron.daily/news - CRON script to purge files in /var/news
        # after 30 days.

        /usr/bin/news -e $EXPIRE -x $EXCLUDE  $EXTRA_OPTIONS

So the probability that you want to change this version of the script is
very low - you would only want to change the variables. Only left would 
be the problem to assign values to these variables. The most common
approach to source in a file only moves the initial problem to another
file: the user changes it and the next version of the package can't deal
with this situation other than offering to "overwrite" it ...

The alternative I'm experimenting with is to use a database.

Currently there is a shell-script implementing such a database featuring
"sed" and "grep". I called this database "cfgdb". Better names are
welcome. With it the expiration of "sysnews" becomes

        #! /bin/sh --
        # /etc/cron.daily/news - CRON script to purge files in /var/news
        # after 30 days.

        /usr/bin/news -e `cfgdb --print  /admin/sysnews/expire`\
                      -x `cfgdb --print  /admin/sysnews/exclude`\
                         `cfgdb --print  /admin/sysnews/extra`\

Or even more efficient:

        #! /bin/sh --
        # /etc/cron.daily/news - CRON script to purge files in /var/news
        # after 30 days.

        /usr/bin/news `cfgdb --prefix="/admin/sysnews/" \
                             --format="-e %s  -x %s  %s" \
                             --print expire exclude extra `

Now if a package maintainer must change the value of "expire", he can
easily ask the user for permission:

        I has been found that setting the value of /admin/sysnews/expire
        to 5 days works better in most cases.
        Here is the explanation for this setting:

        #
        #  The maximum age of a document before it gets deleted
        #  automatically.
        #

        Do the recommended change? (y/n)

The explanation is part of the settings in the database and is shown by
the option "--explain /admin/sysnews/expire". If the user answers "y", he
can execute the command

        cfgdb --set /admin/sysnews/expire 5

Before asking the question above he would check for existance of the
entry, of course:

        if cfgdb --exists /admin/sysnews/expire
        then
            <ask question>
        fi


If you're interested in further examples and all upcoming questions, then
please subscribe to the mailinglist "debian-admintool" by sending the word
"subscribe" to "debian-admintool-REQUEST@lists.debian.org".

The next version of "cfgdb" is released RSN and will be announced
seperatly.

-Winfried



--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com


Reply to: