Re: deb-cfmgr: Debian conffile prompting tool.
On Sun, Mar 26, 2000 at 04:50:48PM -0000, Tom Rothamel wrote:
> On 26 Mar 2000 11:33:53 -0500, Ben Collins wrote:
> >
> > Wichert is just asking that the frontend/program use debconf.
>
> I'll try, but unless I'm missing something, the conffile replacement
> questions don't seem to neatly map onto the debconf way of doing
> things. (For example, how would a user ask to see a diff between new
> and old conffiles?)
>
> I'm not against debconf... I'd really like to not have to go and write
> much interface code. It's just that I'm not sure if I can give an
> interface that's comparable with what dpkg asks now while using a
> debconf frontend.
>
> (This shouldn't be read as disparaging of debconf... it's just that
> the type of information it collects (persistant user information)
> isn't the same as what deb-cfmgr needs (quick user interaction.))
Quite, but I'm sure you'll find debconf very able to handle that.
Basically you will only have one question, with a different default answer
depending on what dpkg wants (sometimes keep the old file is the default,
sometimes keeping the new file is). Which ever way, this should be able to
work in non-interactive, and choose the default (that dpkg decides). Also,
you should leave the program open enough so that it can expand.
Some day, I forsee versioned config files that can give the program some
idea of how important that changes are (based on the version increases).
Also, a merging interface (I'de really like to see something that can not
only diff and merge, but selectively merge changes, and also allow the
user to edit the changes right at that moment in the install). Just
thoughts, and not all of it will happen, but expect it, and code for it.
> > I'm totally against this whole thing mind you, unless dpkg retains
> > someway of working without debconf, or an external program, as a
> > fall back. I don't want a broken perl upgrade to kill my package
> > system.
>
> I quite agree... That's why I'd expect any patch that makes dpkg call
> an external program be optional and off by default, unless a command
> line option is give to dpkg. (Which is something that apt should be
> able to do without many problems, and I'd expect most of this stuff to
> be only useful during apt upgrades.) The old prompting code would be
> left in dpkg, but it only would be called if the command line option
> wasn't given or execution failed or returned an error. This way, we
> can gain features without losing the standalone reliability that dpkg
> already has.
>
> Does this alleviate some of your concern?
Yes, my thoughts exactly.
--
-----------=======-=-======-=========-----------=====------------=-=------
/ Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \
` bcollins@debian.org -- bcollins@openldap.org -- bmc@visi.net '
`---=========------=======-------------=-=-----=-===-======-------=--=---'
Reply to: