Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
Henning Makholm <firstname.lastname@example.org> wrote:
> Scripsit Frank Küster <email@example.com>
>> These variables can be changed by a configuration file, and some of them
>> *must* be set. Now if a user refuses to accept the change that switches
>> from VARTEXMF to TEXMFVAR (or TEXMFSYSVAR, actually), TeX can no longer
> You seem to assume that the *only* way to get this change into the
> file is to forcibly discard all of the sysadmin's local adaptations
> and install a pristine upstream version of the conffile.
No, of course there is an other way: dpkg offers an option to start a
shell (or put itself in the background or whatever) to clear up the
situation; or one can simply log in on a different terminal. But if the
local admin doesn't want to do that, but delay merging the configuration
file, there are only two possibilities: Either he accepts the new
maintainer's version, or he refuses it. And the latter choice leads to
a failure of the postinst script in some cases.
It's only *some* cases; I think in the most important cases, the file
isn't dpkg-managed (but ucf-managed), anyway, so we choose to forcibly
introduce the variable name changes if the rest of the line was
unchanged (or "recognizable"). But that cannot always be done, and in
fact the reason why I decided to ask this is because a user had an old
version of a conffile of an other package. The other package depends on
tetex, and must recreate its format ("reinitialize") when tetex is
updated - and made tetex's postinst fail.
> Why do you want to deny the sysadmin the opportunity to do the changes
I don't. All I do is request some support for the view that if he
decides to do so, he should in fact do it before filing a bug; and if he
files a bug that I can close or downgrade it to non-RC severity.
Inst. f. Biochemie der Univ. Zürich