On Tue, Jul 31, 2012 at 05:21:38PM +0200, Raphael Hertzog wrote: > On Fri, 13 Jul 2012, Josh Triplett wrote: > > On Fri, Jul 13, 2012 at 05:26:28PM +0200, Raphael Hertzog wrote: > > > Michael Biebl reported in the thread at > > > http://lists.debian.org/[email protected] > > > that the difficulty was to handle the case where the target > > > package has no guaranty to be installed. In that case, we > > > might keep the old conffile around when we don't really > > > want. > > > > > > In http://lists.debian.org/[email protected] > > > I suggested to create a rm_conffile_if_owner helper > > > function to deal with this case. > > > > > > Would this fit your needs too? > > > > I *think* that would work. I don't need support for moving conffiles > > between arbitrary packages, just support for allowing package2 to take > > over a conffile from package1, and allowing package1 to drop the > > conffile if not installing package2. How would rm_conffile_if_owner > > behave with a modified conffile? > > Just like rm_conffile. It would keep a ".dpkg-bak" copy of the file. > > > Would it keep the conffile around in a way that allows the new package > > to take it over with the old contents still intact? > > Hum, not sure. At least I was not intending it that way. I was rather > imagining that the dependencies would force the upgrade of the target > package at the same time. That is package1 would break the versions of > package2 that don't have the conffile. > > That way, in package1's postinst we can be sure that: > - either package2 has taken the file over > - or package2 is not installed
Consider the original motivation for this. You have a package A, which contains a daemon B and an init script /etc/init.d/B. You split B and its init script (and any other configuration files for it) into its own package, which A does not depend on. If installing B, you want to preserve the configuration of B. B didn't exist beforehand, so no package exists for A to declare a Breaks against. However, nothing guarantees that the user will install B at the same time as upgrading A. In particular, it seems highly likely that a user who wants B will upgrade A, read the NEWS.Debian file, and then choose whether to install B. - Josh Triplett -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
