Frank Lichtenheld <[EMAIL PROTECTED]> wrote: > On Mon, Oct 31, 2005 at 06:56:44PM +0100, Frank Küster wrote: >> In my opinion this is not a bug (except if the package is crucial for >> the system to work and be reachable, like ssh) - the local admin simply >> has to review the changes to conffiles that dpkg requested, and have a >> look at NEWS.Debian and changelog.Debian. If these files do not contain >> enough information to fix the system, then this is a bug, right? But >> the simple fact that a postinst script fails because a change has been >> refused isn't - and for sure it is not a serious or grave bug, >> severities often used when a postinst fails. >> >> Opinions? > > There is one big problem with that scenario that I haven't seen > mentioned in this thread yet: If I make the dist-upgrade of a machine > from sarge to etch and the dist-upgrade fails right in the middle > of the installed 3000 packages I will be severly disappointed to > say the least if that didn't happen for a very good reason... > That's a fact that often gets lost when discussing such problem from > developer to developer that install sid on their machines and update > about 30 packages at once.
Maybe we need a policy (or a change in dpkg's default behavior) for that. One option would be to recommend to take the new version and merge local changes afterwards (but this might severely break more important things, like ssh in an environment where port 22 is blocked...). Or on the other hand, packages that change incompatibly must ensure that they are not installed automatically - however that would mean that every package that build-depends on the changed package would have to change its control file. > So if it is at all possible to avoid failing the postinst (which of > course also means to not break other packages installation as you > have pointed out) it should be done. > > If it is at all possible in the case of tetex I can't tell, though. I do not see how it could be made possible. Oh, yes, there is one way, and we have even tried to go that route: After the conffile questions have been asked, we check in the postinst script whether some essential entries in ucf-managed configuration files are wrong, and if they are we change the file. But we can't do that for dpkg-managed files, and in any case I don't want to have a 1000 line postinst script because it checks for 30 possibly fatal refused changes... Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer