Moving a conffile from one package to another seems to prove even more
difficult than renaming it or removing it.  Please consider providing
support for this case in dpkg-maintscript-helper.

Thanks,
Josh Triplett

retitle 595112 dpkg-maintscript-helper: new helper for moving a conffile between packages
thanks

What kind of problems are you referring to?

Michael Biebl reported in the thread at
http://lists.debian.org/4F31C323.9090606@debian.org
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/20120209095814.GA3452@rivendell.home.ouaza.com
I suggested to create a rm_conffile_if_owner helper
function to deal with this case.

Would this fit your needs too?

Cheers,

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?  Would it keep the conffile around in a
way that allows the new package to take it over with the old contents
still intact?  And, would this also ensure that the conffile (even if
modified) gets removed when purging package1, if not yet taken over by
package2?

- Josh Triplett

Hi,

Just like rm_conffile. It would keep a ".dpkg-bak" copy of the file.
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

Yes, that should be part of the contract of rm_conffile_if_owner. But
it will only have to deal with this in the case of a modified conffile
(since the non-modified conffile would be pruned before-hand in the
postinst).

Cheers,

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

OK so we really need a "recover_conffile" which would be used in
package2 and would move a .dpkg-bak copy in its original place.

Cheers,

That sounds perfect.  Package A would use rm_conffile, which would move
a modified conffile to .dpkg-bak; package B would ship a default
configuration file, and use recover_conffile, which would move the
.dpkg-bak file over the top of the default configuration file if it
exists.

- Josh Triplett

In systemd, we split a new package systemd-container. We used the
approach to rm_conffile in systemd for the appropriate version, and
added the following snippet to systemd-container:

machine_policy=/etc/dbus-1/system.d/org.freedesktop.machine1.conf
if [ "$1" = configure ] && [ -z "$2" ] && [ -f
${machine_policy}.dpkg-bak ] ; then
   md5sum="$(md5sum ${machine_policy} | sed -e 's/ .*//')"
   old_md5sum="$(dpkg-query -W -f='${Conffiles}' systemd-container | \
                       sed -n -e "\' ${machine_policy} ' { s/
obsolete$//; s/.* //; p }")"
   # On new installs, if the policy file was preserved on systemd upgrade
   # by dpkg-maintscript helper, copy it back if the new file has not
been modified yet
   if [ "$md5sum" = "$old_md5sum" ] ; then
       mv ${machine_policy}.dpkg-bak ${machine_policy}
   fi
fi

Because this is a new package, we test -z "$2". If this was a move
between pre-existing packages, then the test should be with dpkg
--compare-versions

So far we have not received bugs about this usage.

A caveat to be aware of, is that the advice given by the man page to
use the version where the rm_conffile command is added is not
appropriate for this use case: because now the file is owned by a
different package, one should not try to remove the file in a version
later than the one that actually stops shipping the file. This implies
that if one moves a conffile between packages but forgets to add the
maintscript helpers, and adds the helpers in a later version, then the
orphaned conffile will remain if the new package is not installed.
This is unfortunate but we did not find a way to reliably determine
when the file can actually be removed.

Please implement this helper in dpkg-maintscript-helper; it seems we
will need this a lot if we decide split up the systemd package
further.

Saludos

Please find attached a patch to kickstart the discussion.
Documentation is missing. accept_conffile will move a .dpkg-bak file
left from rm_conffile if upgrading from a version older than the
passed version (or only on first install if empy is passed as
version).