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

Re: debconf and cluster management

On Fri, Feb 15, 2002 at 09:21:22AM +0100, Marcelo E. Magallon wrote:
>  AFAIK, the argument goes like this: "Hey, let's have this in policy"
>  "Do the majority of (affected) packages do that already?" "Uhm, no..."
>  "Bad luck then".

   At the Debian miniconference in Brisbane it was reported that most
packages *are* using debconf.  I don't think I believe that, but I might buy
that most packages with interactive configuration are using debconf now.  At
the moment, of 3023 packages in my available file, the string debconf
appears only 179 times.  Shortly before debconf was first released I scanned
all my *.postinst for "read", and found that only about 10% had interactive
scripts, and many (most?) of those were wrapped in conditionals and not
normally executed.  At the moment, "read " appears in only 66 of the
postinsts of the 2359 packages installed on this machine.  Interactive
postinsts seem to be an even smaller minority today, and in many cases
probably really should stop and ask the sysadmin ("should I reinitialize
your postgresql database, or would you like to dump it out first?").
   Most of the interaction I get these days is just deciding whether to
overwrite modified config files.  Solve just that and Debian would be quite
cluster friendly in even fully managed node layouts.  I'd just as soon push
new config files out first, and then upgrade everything, keeping my own
modified files (and maintainers' packaged config files in all other cases). 
Does the envisaged debconf driven cluster configuration backend support this
sort of decision?  As far as I know nothing has tried to interfere with
dpkg's fairly chatty config file management.  And how about cluster-wide
dpkg-reconfigure?  :)


Reply to: