On Tue, 31 Jul 2012 20:47:06 +0200 Raphael Hertzog <hert...@debian.org> wrote:
> On Tue, 31 Jul 2012, Josh Triplett wrote:
> > 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.
>
> 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.

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

Reply via email to