Re: Debconf problem
Hi Joey,
thanks for being patient with me. I promise that I'll write this up
(for debconf-devel(7) or the developer's reference or whatever you
suggest) once we've sorted this out.
Joey Hess <joeyh@debian.org> wrote:
>> Does that mean I must use some hackish handmade flags that are reset
>> only at the end of the postinst, and thus indicate whether there was a
>> postinst run after the last config run?
>
> No, it means that you're taking the wrong approach to using debconf.
> I've been trying to point you at tools that will lead to an appropriate
> solution.
Ah, I see.
> 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?
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.
Now if I just let the system be as it is, I kind of leave these users
alone. But maybe you are right and this is the only solution - we could
indicate in NEWS.Debian that everybody who wants debconf management
should reconfigure the package. But then, why not ask anyway?
> 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. 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).
To avoid this, and also detect such upgrades, I have to put the
*current* version number into the config script, and only act if the
version passed as installed-version is either empty (fresh install), or
it matches the hardcoded version current number in the script
(reconfigure). And even if I don't forget to update the version number
in the config script, what about NMUs? Binary-only NMUs?
I hope I'm wrong...
Regards, Frank
--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer
Reply to: