Ticket #867 (new enhancement)
config-package-dev should be smart enough to undivert and unremove automatically
Reported by: | andersk | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | The Distant Future |
Component: | config-package-dev | Keywords: | |
Cc: | Fixed in version: | ||
Upstream bug: |
Description
Requiring manual specification of undiverted and unremoved files has been a constant source of upgrade-related bugs. This is dumb. Let’s fix config-package-dev to clean up after itself automatically.
Attachments
Change History
comment:2 Changed 12 years ago by jdreed
I started thinking about this, and one problem comes to mind. While undiverting files is fairly easy, because we know the divert and original extensions, unremoving is harder because we can't compute the encoded filename in the maintainer scripts on the fly (because we don't have encode/decode). This becomes slightly easier, if we decide that if a package uses config-package-dev, it doesn't get to dpkg-divert anything manually, then we know that anything diverted by the package is something to be undiverted/unremoved. IMHO, I think enforcing that requirement is reasonable, and is also probably the only way to guarantee cleaning up after past broken packages, but I'm open to hearing why that's not a reasonable requirement. There's also the screw case of what happens when a package stops using config-package-dev, but still needs to exist (e.g. foo-config used to divert /etc/bar, but now merely drops a file in /etc/bar.d). How do we hook into the maintainer scripts there, when we're not using c-p-d at all in the rules file? We could require explicit unremove/undivert in those cases, but that seems like it would defeat the purpose. Or we could say that by virtue of using c-p-d (whether you include the cdbs rule, or call the debhelper command), you always get a postrm snippet that cleans up diversions?
Thoughts?
comment:3 Changed 12 years ago by jdreed
Actually, wait, that requirement is unnecessary, because in the preinst, on upgrade, we can look at the Conflicts/Provides? of the older version to see what used to be diverted, and save that list somewhere, and then deal in the postinst. Of course, we still need decode...
comment:4 Changed 12 years ago by jdreed
I have a patch for this, attached (and in /mit/jdreed/Public/c-p-d-867.diff). (It's against the Debathena repo, not Git. Hopefully that won't deter anyone from providing feedback.) It doesn't yet handle the case of "This package stops using c-p-d in any way.", but I'd like feedback on the method before I unravel the complexities of cdbs to figure out how best to hook that in.