[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Reply to: