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
Attachment:
signature.asc
Description: Digital signature