Re: Debconf problem
Joey Hess <joeyh@debian.org> 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
Reply to: