Re: debconf and cluster management
On Fri, Feb 15, 2002 at 08:12:59PM +1100, Drake Diedrich wrote:
> 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?").
I've made the same sort of grepping around, and came to the same conclusion.
But this method (and I have no better one) does only detect interactive
shell script. What about the perl ones ? The most proeminent one being
exim...
For the example you give, why should the sysadmin answer this question at
configuration time ? It is possible to detect the dumping-or-not problem
durring debconf configuration, even before unpacking, isn't it ? The action
must be taken in postinst, but the detection of the problem and user
interaction can be done before, I think.
> 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.
I agree, if debconf wants to fullfill the non interactive requierement,
something must be done so that the user can choose which conffile he wants
to keep, and which ones he wants to get ride from before unpacking. It would
need some help from dpkg side, but it is not impossible to do...
Someone else in the thread says that it would be good if people on this list
take care of "debconfizing" the packages, and provide patches to
maintainers. I agree with this. Let's do it, people ! We may run into
problems, because of maintainer not willing to do it, but the only thing
really sure in my point of view is that if nobody do it, it won't get done ;)
Bye, Mt.
--
Si les grands esprits se rencontrent, les petits esprits, eux, se cognent.
Reply to: