Removing obsolete configuration files on upgrade
Hi policy experts, Since policy 3.8.5.0, section 10.7.3 says Obsolete configuration files without local changes should be removed by the package during upgrade. I was trying to apply this to the git package and ran into a little trouble. Consider the following sequence of events: 1. I install package hello-demo version 1, including a conffile /etc/greeting with content 'hello'. 2. I change /etc/greeting to 'hi'. 3. I upgrade hello-demo to version 2, which dropped the customizable greeting functionality. /etc/greeting is obsolete now. Since my greeting was customized, it is retained in /etc/greeting. 4. I change /etc/greeting back to 'hello'. 5. I upgrade hello-demo to version 3, which still does not support customizable greetings. Should /etc/greeting be removed during the upgrade? After all, it is both (a) obsolete and (b) without local changes from the version 1 of the conffile. My hunch is to say that a package may remove /etc/greeting in this case but by no means should. That is, something like the following but hopefully less awkward: Obsolete configuration files without local changes may be removed by the package during upgrade, and should be removed by the package during upgrade from the version before they were obsolete. What do you think? Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131130200353.ga15...@google.com
Re: Removing obsolete configuration files on upgrade
On Sat, Nov 30, 2013 at 12:03:53PM -0800, Jonathan Nieder wrote: Hi policy experts, Since policy 3.8.5.0, section 10.7.3 says Obsolete configuration files without local changes should be removed by the package during upgrade. I was trying to apply this to the git package and ran into a little trouble. Consider the following sequence of events: 1. I install package hello-demo version 1, including a conffile /etc/greeting with content 'hello'. 2. I change /etc/greeting to 'hi'. 3. I upgrade hello-demo to version 2, which dropped the customizable greeting functionality. /etc/greeting is obsolete now. Since my greeting was customized, it is retained in /etc/greeting. 4. I change /etc/greeting back to 'hello'. 5. I upgrade hello-demo to version 3, which still does not support customizable greetings. Should /etc/greeting be removed during the upgrade? After all, it is both (a) obsolete and (b) without local changes from the version 1 of the conffile. My hunch is to say that a package may remove /etc/greeting in this case but by no means should. That is, something like the following but hopefully less awkward: Obsolete configuration files without local changes may be removed by the package during upgrade, and should be removed by the package during upgrade from the version before they were obsolete. What do you think? I htink policy is mostly concerned by upgrade between stable release, and hence only one upgrade is considered. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131130201427.GE13881@yellowpig
Re: Removing obsolete configuration files on upgrade
On Sat, Nov 30, 2013 at 12:03:53PM -0800, Jonathan Nieder wrote: My hunch is to say that a package may remove /etc/greeting in this case but by no means should. That is, something like the following but hopefully less awkward: Obsolete configuration files without local changes may be removed by the package during upgrade, and should be removed by the package during upgrade from the version before they were obsolete. What do you think? What does upgrade from the version before they were obsolete mean? Does this mean the stable version before they were obsolete? Or any version before they were obsolete? Perhaps during upgrade from a version before they were obsolete would be better? More significantly, how does this suggestion help in your case? It doesn't seem to mention it; it only mentions the regular case. Julian -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131130201343.ga7...@d-and-j.net
Re: Removing obsolete configuration files on upgrade
On Sat, Nov 30, 2013 at 12:03:53PM -0800, Jonathan Nieder wrote: Hi policy experts, Since policy 3.8.5.0, section 10.7.3 says Obsolete configuration files without local changes should be removed by the package during upgrade. I was trying to apply this to the git package and ran into a little trouble. Consider the following sequence of events: 1. I install package hello-demo version 1, including a conffile /etc/greeting with content 'hello'. 2. I change /etc/greeting to 'hi'. 3. I upgrade hello-demo to version 2, which dropped the customizable greeting functionality. /etc/greeting is obsolete now. Since my greeting was customized, it is retained in /etc/greeting. 4. I change /etc/greeting back to 'hello'. 5. I upgrade hello-demo to version 3, which still does not support customizable greetings. Should /etc/greeting be removed during the upgrade? After all, it is both (a) obsolete and (b) without local changes from the version 1 of the conffile. I would say an it should only check this the first time it's upgraded from a version that did have the conffile to a version that doesn't, but may optionally check this on any upgrade. Is dpkg-maintscript-helper doing something you didn't expect? Kurt -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131201001940.ga12...@roeckx.be
Re: Removing obsolete configuration files on upgrade
Kurt Roeckx k...@roeckx.be writes: I would say an it should only check this the first time it's upgraded from a version that did have the conffile to a version that doesn't, but may optionally check this on any upgrade. That sounds right to me too. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87haatpgjb@windlord.stanford.edu
