On Jul 13 12:17, Dave Korn wrote: > On 13 July 2007 12:11, Corinna Vinschen wrote: > > I'm a bit reluctant to present a generic auto-merge. Consider the > > situation where a new version of a package adds a new configuration > > setting. An auto-merge would pull in the default setting for this > > one, without the user knowing about this > > You mean like, for instance, sshd introduces a new vital security-related > config option such as PrivSep and if the user doesn't know to turn it off > manually it gets enabled by default? Sounds like a good thing to me ....!
There are other packages which just change their default behaviour because the upstream author thinks it's a good idea, not because it has any security impact. > (Plus it's not any different from the situation where the user installs the > package for the first time and doesn't bother to customize the config). Not quite. The situation we're talking about is one in which the user *did* care and changed the config file to his or her own needs. When a new release just merges in changes without notifying the user about this, it's not exactly nice. > I know the idea of automerge is scary. Yes, indeed. Think of complex files like /etc/profile or /etc/csh.cshrc. How do you make sure that a merge didn't just work (patch returned without error), but that the merge actually had a still working result? I think merging is not feasible for all files in /etc. > I guess we should make sure there's > a very very easy roll-back mechanism that we can point users at if something > goes wrong and that would just restore their prior config exactly as it was > before the merge. If we really do merges, a merge should always generate a copy of the original file and setup should notify the user. The way Andrew described it would still be a good thing, even if an auto-merge went fine. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
