sean finney wrote: > 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 think the only value that is absolutely required is dbtype. > 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. If we do this, then we avoid the problem of the dbtype being always set for single forced type packages. >> 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 :) Yes, this is what happens, but if d-l-i doesn't return a dbtype then the setting to seen fails. So I'll whip up a patch that ignores the d-l-i import if a) dbtype is unset OR b) d-l-i returns non-zero error status If dbtype is set and d-l-i returns zero, the other values are pre-seeded as per the current behaviour and installation proceeds as per normal. I think that will fix the original bug and work in the exception cases you pointed out. Cheers -- Matt Brown Debian Developer [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz
signature.asc
Description: OpenPGP digital signature
