Frank Küster wrote: > Because it isn't true that the previous version didn't use debconf. It > just asked the questions totally differently and took an approach that I > now would call flawed. But still it gave the users the impression that > their ls-R files' permissions are managed by debconf, and probably many > thought they were properly managed and didn't do any manual changes. Well, assuming that your debconf questions are different from the ones it asked before, this is the same as not having had questions before. Consider what I've said before to operate on a per-question basis. (In other words, I'm suggesting that you rename your questions and ask the new ones on upgrade from the broken versions of the package.) > > The parameters passed to the config script can be used to detect the > > upgrade and not ask any questions or populate the debconf database at > > all, while leaving debconf asking the question on fresh installs and > > when reconfigured. > > Oh, but that seems very hard to do right: The only way to differentiate > between an upgrade and reconfigure seems to be the version number of the > last installed version. No, in an upgrade, $2 is "configure", for a reconfigure $2 is "reconfigure". > But since one could install the package noninteractively, but switch > to an interactive frontend before an upgrade, I would have to avoid > asking questions for *any* last-installed version number older than > the current one (if I decide not to ask and act at all upon upgrade). Only if the noninteractive install ran with DEBCONF_NONINTERACTIVE_SEEN not set to true. Not setting that to true by default is agruably a bug in debconf since it does lead to this edge condition, but it's not an edge case I would worry about dealing with in your package. -- see shy jo
Attachment:
signature.asc
Description: Digital signature