hey matt, On Tue, 2006-11-07 at 09:47 +1300, Matt Brown wrote: > > what if the app is a single dbtype application (and thus always has > > dbc_dbtype set)? otherwise, i agree with the approach, and it cleans > > up the state machine area quite a bit which is a good thing. > > Hmm, that could be a problem yes. Unfortunately I'm not familiar with > all the nuances of dbconfig-common to know what a good solution to this > is. I could check every return value from dbconfig-load-include and only > error out if they are all blank, or we could get more sophisticated and > check only the required values for the selected database type...
the problem is most/all of the values can be blank, depending on the
package. for example, an unset db_port setting means the default port,
likewise for the host, and in some instances applications will even
default to a hardcoded user. of course if all of the values are blank
at the same time, that could be a sign that there's a problem...
i can't recall right now if it's already the case, but for some cases
if the file can't be read or parsed, we could rig d-l-i to return
nonzero error status and catch it in the relevant maintscript hooks.
> Perhaps the real solution is to make dbconfig-load-include only act as
> hints and have the user still asked the questions...
this is an option. in fact, this is already what's happening iirc, but
the questions are explicitly set as "seen" so they're not prompted, i
*think*. so making this happen would probably mean less code as opposed
to more :)
another option would be to display the settings according to d-l-i in a
debconf prompt, and ask the admin to confirm them. of course, if
there's a problem with the settings, there's probably not much that the
admin can do that couldn't be done afterwards as well.
sean
signature.asc
Description: This is a digitally signed message part
