Ticket #867 (new enhancement)

Opened 10 years ago

Last modified 8 years ago

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:


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.


c-p-d-867.diff Download (5.7 KB) - added by jdreed 8 years ago.
Proposed patch

Change History

comment:1 Changed 8 years ago by jdreed

  • Component changed from -- to config-package-dev

comment:2 Changed 8 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?


comment:3 Changed 8 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...

Changed 8 years ago by jdreed

Proposed patch

comment:4 Changed 8 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.

comment:5 Changed 8 years ago by jdreed

Er, I lied, this does handle the case of "we're no longer diverting anything" if you set DEB_DIVERT_PACKAGES to the package's name. That's probably Wrong(tm), and we should consider DEB_DIVERT_CLEANUP_ONLY or something.

Note: See TracTickets for help on using tickets.