Henning Makholm <[EMAIL PROTECTED]> wrote: > Scripsit Frank Küster <[EMAIL PROTECTED]> >> Henning Makholm <[EMAIL PROTECTED]> wrote: > >>> 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. > > Exactly, but what happens then is > > 1. User backgrounds dpkg, or switches to another window. > 2. User edits the file to take into account the new variable name. > 3. User returns to dpkg. > 4. User selects the "No, I'm happy with my own version as it look > now" menu option. > > Your proposal, if I understand you correctly, is to make (4) result in > the postinst failing even though the user _has_ taken care of the problem.
You must have misunderstood me. I don't check whether the installed file is the one I expect; I simply run "fmtutil --all" - and that will fail if he hasn't solved the problem. >> 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. > > This is not true. It is - with "that" I meant to edit the file now. > If he edits the file himself (but refuses the > maintainer's version because accepting it would lead to his own > changes being overwritten) things still work fine. Of course they will. In particular, I won't get a bug report and won't have to consider closing or downgrading it, and ask questions on -devel :-) >>> Why do you want to deny the sysadmin the opportunity to do the changes >>> himself? > >> I don't. > > You want the postinst to fail if he does the changes himself rather > than abandoning all of his local changes, right? No, if I have written something like this I must have been insane. All I want to say is: If he does the changes himself bug does it wrong, the fmtutil call (or updmap or whatever) in postinst will fail. But this is in fact a corner case, the usual situation is that the user pressed "keep local version" without thinking, or simply uses the noninteractive frontend and doesn't bother himself with looking at any *.dpkg-new files before reporting the bug. >> 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; > > Of course it is not a bug if the package fails because the admin does > not properly adjust his conffiles. So finally there is one person who simply says "yes" to the question in the first mail, thank you. By the way, I don't think that the answer should be a simple "yes": If a failure to configure might cause the system to be inaccessible over the net, the package maintainer has to take care to avoid this (i.e. ask a non-debconfized question in preinst, as glibc does). Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer