On Fri, 4 Dec 2009 19:25:54 +0100 gregor herrmann <gregoa@debian.org> wrote: > On Fri, 04 Dec 2009 17:32:13 +0000, Neil Williams wrote: > > > > Configuration file `/etc/sensors3.conf' > > > ==> File on system created by you or by a script. > > > ==> File also in package provided by package maintainer. > > > What would you like to do about it ? Your options are: > > > Y or I : install the package maintainer's version > > > N or O : keep your currently-installed version > > > D : show the differences between the versions > > > Z : background this process to examine the situation > > > The default action is to keep your current version. > > > *** sensors3.conf (Y/I/N/O/D/Z) [default=N] ? > > That is a bug in the package, as described in my other reply. If the > > user hasn't changed that file, the package should be able to cope > > with the changes without prompting. Whichever package caused the > > file to be modified in such a way that it cannot be upgraded > > cleanly is BUGGY. > > If the file is unmodified, then there's indeed something wrong. But > the interesting case is when the admin has changed something. The > common case that is getting on my nerves currently is: > > * foo 1.0 ships /etc/foo.conf with > featureA=yes > featureB=no > * I change featureB to yes > * foo 2.0 ships /etc/foo.conf with > featureA=yes > featureB=no > featureC=7 > * Now dpkg ask if I want the new version or my modified one. But what > I actually want is > - keep my change of the featureB variable and > - add the new featureC variable > * Or more generally: I want to preserve my locally modified values > and at the same time update the rest which I haven't touched. That's a user change, I thought the point of this was that changes *not done by users* are causing problems. Different problem. > And that's what Config::Model allows, as far as I understood it. That's not how I understood the purposes of it, although it could be used that way, it isn't sufficient justification IMHO. If admins make changes, admins should expect to handle the dpkg conflicts. I thought the idea of this was to handle changes not made by users - I think we agree that those instances are bugs. > > > Avoid asking users configuration questions during packages > > > upgrades. This could make dist-upgrades between Debian releases > > > easier. > > No, it hides the problem inside another dependency. The package > > should handle it's own config files *and* the bugs that result. > > I don't consider writing parsers in each and every .postinst very > efficient. As is adding a perl dependency to packages that have no previous need for perl. The postinst doesn't have to parse the conffile, it just has to not generate the dpkg result (by generating the conffile instead of packaging it) and allow the app to transition from one to the next. If the existing file is different to what the package thinks it can upgrade, the package should not require dpkg to generate the error and the consequent halt of the package installation. What we see from dpkg should (IMHO) *only* appear as a direct result of a bug that then needs to be fixed in the package. If the package can anticipate that dpkg will have problems, the package should handle that in advance. By the time it's left to dpkg it's too late. Doesn't justify a separate parser. -- Neil Williams ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/
Attachment:
pgp_iJz_XfXbr.pgp
Description: PGP signature