Re: correctly using other packages in postrm
On Mon, May 31, 2010 at 09:02:50PM -0700, Steve Langasek wrote: Hmm, what's the risk of changing it? I guess if dependencies are allowed to be purged when a package depending on them is removed-but-not-purged, dbconfig-common could obliterate config files that the depending package expects to still have around. Is that the concern? one of them, yeah. if dbc were to guarantee that it left no cruft behind, it would have to purge all the files it registered in proxy for packages when it was purged as well (which also means this would need to be tracked, which it isn't atm), but i don't feel confident enough without looking to know whether that would cause a problem in the depending packages' maintainer scripts. likewise, if dbc started purging these files as part of the postrm hook for the depending package, i'd be concerned that if this code was duplicated in the postrm script that it would result in a failure if it were run a a second time (i.e. the maintainer script already dealt with the file or tried to deal with it after calling the hook). it could be that they're both non-issues (now that i check, ucf seems to be fine with puring a config file that isn't registered, for example), but i'd want to do some kind of audit and loose testing to know for sure before i instabug a large number of packages. sean signature.asc Description: Digital signature
Re: correctly using other packages in postrm
Hi Evgeni, On Thu, May 27, 2010 at 11:32:06AM +0200, Evgeni Golov wrote: This means that we *try* to execute the postrm-hook of dbconfig-common in our postrm, but only if it's there. Policy 7.2 says The Depends field should also be used if the postinst, prerm or postrm scripts require the package to be present in order to run. Note, however, that the postrm cannot rely on any non-essential packages to be present during the purge phase., which allows dbconfig-common to be gone *before* our postrm is executed. If it is gone, the hook isn't called, /etc/dbconfig-common/bley.conf isn't removed and piuparts warns about it. That's perfectly correct, we leave a stale config file here, so how to fix it? Trivial solution would be something like: if [ -f /usr/share/dbconfig-common/dpkg/postrm ]; then . /usr/share/dbconfig-common/dpkg/postrm dbc_go bley $@ else rm -f /etc/dbconfig-common/bley.conf if which ucf /dev/null 21; then ucf --purge /etc/dbconfig-common/bley.conf ucfr --purge bley /etc/dbconfig-common/bley.conf fi fi Does dbconfig-common know about all of these config files? I think it's the responsibility of dbconfig-common to track them, and remove them on purge. That way if your package is purged while dbconfig-common is installed, the config file is removed, and if dbconfig-common is removed before purge, a dpkg --purge dbconfig-common can still clean it up. This is similar to how ucf's cache is already handled, btw. Alternatively, we could modify piuparts not to remove dbconfig-common before the tested package isn't gone (or actually: not to try to remove any deps before the tested package isn't gone) and thus ignore this problem, defining it as not usual usecase (who tries to remove deps before removing the package itself?). Piuparts should include purging dbconfig-common (i.e.: all dependencies that it installed) as part of this test. If it does, and the config file is left behind, this is a dbconfig-common bug, IMHO. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100531192448.ga30...@dario.dodds.net
Re: correctly using other packages in postrm
hi, On Mon, May 31, 2010 at 12:24:48PM -0700, Steve Langasek wrote: Does dbconfig-common know about all of these config files? I think it's the responsibility of dbconfig-common to track them, and remove them on purge. That way if your package is purged while dbconfig-common is installed, the config file is removed, and if dbconfig-common is removed before purge, a dpkg --purge dbconfig-common can still clean it up. i think in hindsight that's the way it *should* have been, but the documentation has suggested the contrary for long enough that i'm hesitant to break things, at least this late into the release cycle. sean signature.asc Description: Digital signature
Re: correctly using other packages in postrm
On Tue, Jun 01, 2010 at 01:13:28AM +0200, sean finney wrote: On Mon, May 31, 2010 at 12:24:48PM -0700, Steve Langasek wrote: Does dbconfig-common know about all of these config files? I think it's the responsibility of dbconfig-common to track them, and remove them on purge. That way if your package is purged while dbconfig-common is installed, the config file is removed, and if dbconfig-common is removed before purge, a dpkg --purge dbconfig-common can still clean it up. i think in hindsight that's the way it *should* have been, but the documentation has suggested the contrary for long enough that i'm hesitant to break things, at least this late into the release cycle. Hmm, what's the risk of changing it? I guess if dependencies are allowed to be purged when a package depending on them is removed-but-not-purged, dbconfig-common could obliterate config files that the depending package expects to still have around. Is that the concern? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100601040250.ga9...@dario.dodds.net
Re: correctly using other packages in postrm
* Evgeni Golov evg...@debian.org [100527 11:32]: Alternatively, we could modify piuparts not to remove dbconfig-common before the tested package isn't gone (or actually: not to try to remove any deps before the tested package isn't gone) and thus ignore this problem, defining it as not usual usecase (who tries to remove deps before removing the package itself?). I would have thought most people do this most of the time. Most commands only remove stuff, unless you tell them explicitly. (So you keep the config files and only later when you know you have not removed anything you need, you can purge it, so reinstalling would now mean reconfiguring). Bernhard R. Link -- Never contain programs so few bugs, as when no debugging tools are available! Niklaus Wirth -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100527150107.gb1...@pcpool00.mathematik.uni-freiburg.de
