On Sun, Mar 22, 2015 at 04:01:30PM -0400, James Cloos wrote: > I didn't read much of this thread at it occurred; am catching up now. > > It is absolutely and unquestionably essential that no file in /etc which > has *any* local modifications ever be edited on package upgrade w/o the > admin's consent. > > Adding users and groups on install is one thing, editing a locally > edited config file during a package upgrade w/o asking for permission, > OTOH, is UNacceptable.
This is naïve in the context of sshd_config, I'm afraid. (For details, see the postinst, and it's worth noting that most of the necessary upgrade fixes applied there have been non-events and haven't attracted this sort of well-meaning commentary.) > The normal dialog, with the options for seeing the diff, accepting the > maintainers' version, keeping the local version or starting a shell > manually to handle it, works fine. > > The openssh package should use that just like everything else. Firstly, "everything else" is a gross exaggeration. Many configuration files certainly are dpkg-managed conffiles, but many are not. dpkg implements a simple baseline algorithm for managing configuration files which is appropriate for a subset of them. Secondly: that would perhaps be nice, but we can't get there from here. Due to what I view as historical errors, sshd_config doesn't really have a single canonical state on all upgraded systems. If it had been a dpkg-managed conffile from the start then that would have been much better, but as it is we have to make do with what we have. Although I would point out that if sshd_config had been dpkg-managed then there would have been multiple grave bugs in the past about sshd failing to start on upgrade due to people failing to notice the changes they had to merge, so, you know, we kind of have to consider practicalities as well as ideals here. Anyway, I would appreciate it if people could refrain from filling my mailbox further about this bug. :-) I haven't had time to deal with it over the last couple of days (Debian developer in having a social life shocker!), but in brief I intend to revert the offending change in its entirety as it's clearly causing far more trouble than it can possibly be worth. I'll post further rationale when I get half a chance. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150322203546.gh3...@riva.ucam.org
