Joey Hess <[EMAIL PROTECTED]> wrote: > 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.)
In the previous mail, I understood you suggested to not at all ask questions on upgrade: ,---- | Your package is being converted from a previous version, which did not | use debconf and did have the files, to a version which does use debconf. | So why ask the question on upgrade from this previous version at all? `---- So I'm confused. >> > 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". Stupid me, I can't read. >> 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. Okay, thanks - is this variable documented anywhere? Things getting clearer, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
