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

Re: dpkg-reconfigure, policy, and least surprise principle



* Mark Brown 

| On Sun, Dec 02, 2001 at 12:36:26PM +0100, Tollef Fog Heen wrote:
| > * Roland Mas 
| 
| > |   A hypothetical third hand would be holding this: the postinst first
| > | reads the master config file and shoves its values into Debconf, then
| 
| > This is the right way, though.  Note that unless the admin has asked
| > for it, previously answered debconf questions won't be asked again,
| > so you wouldn't bother the admin too much.
| 
| I've done this in one of my packages too but I worry what will happen
| when Debconf finally gets support for remote databases.

That will probably be a problem if the DB is read-only, yes.

joeyh, any thoughts on this one?

| At that point the configuration on the system where the
| configuration front end is running may not be the configuration of
| the system that is being configured.

I don't care where the frontend is running, but I know that the system
where the config script is running is the system which is being
configured.  This might not be the place where the backend DB is
running, though.

So we might have a problem with code which looks like:

#! /bin/sh -e

. /usr/share/debconf/confmodule

if [ -e /etc/suck/get-news.conf ]; then
    remoteserver=`grep remoteserver /etc/suck/get-news.conf | cut -d: -f 2-`
fi
if [ "$remoteserver" ]; then
    db_set suck/get-news/remoteserver $remoteserver
fi

db_input medium suck/get-news/remoteserver || true
db_go || true

and then postinst:

#! /bin/sh -e

. /usr/share/debconf/confmodule
if [ ! -f /etc/suck/get-news.conf ]; then
    cp /usr/share/doc/suck/examples/get-news.conf /etc/suck/get-news.conf
fi

db_get suck/get-news/remoteserver
sed -e "s/remoteserver:.*$/remoteserver: $RET/" /etc/suck/get-news.conf > /etc/suck/get-news.conf.tmp$$
mv /etc/suck/get-news.conf.tmp$$ /etc/suck/get-news.conf

(Yes, I know about not copying from /usr/share/doc, but haven't fixed
it yet.)

This _will_ overwrite the local values, unless Debconf has a writable,
local DB as well.  I really don't see how to implement this without a
writable DB.  Is having a writable DB somewhere a requirement of
Debconf or is my code broken?  If it's broken, what is the fix?

-- 

Tollef Fog Heen
Axiom #1: You Can't Win



Reply to: