[Bug 1694159] Re: Complete libvirt migration to Debian style packaging (dependencies, conffiles)

[ChristianEhrhardt]

It turns out mv_conffile + package rename doesn't work correctly.
It would not realize there was a changed conffile and drop the old content completely.
It would neither retain in moved file, nor in dpkg-bak which is the worst case.

Furthermore and more important is that the the combination of
  mv A B oldver
  rm B newver
doesn't work.
This is needed to mv-retain data on LTS->LTS upgrade which "can still be saved".
While at the same time drop obsolete conffiles (including retain custom data in backups)
But instead the preinst of the RM will make the conffile unavailable for the postinst of the MV.
The postinst of RM will then remove it.
So that is equivalent to "just" RM.
Note: if MV finds an equal md5sum it is actually a RM in via .dpkg-remove
Overview:
          diff                                     default
pre mv -  does nothing                             mv .dpkg-remove
pre rm -  mv .dpkg-backup                          mv .dpkg-remove
post rm - would mv, but named .dpkg-backup now     rm .dpkg-remove
post rm - .dpkg-backup to dpkg-bak                 rm .dpkg-remove


The conffiles that changed were those that almost never have user changes, still we want to make it correct. So the implmentation tries to move old changes where applicable, but in a few cases only creates backups to not interfere too much.
So likle 99% of the cases there won't be changes anyway and it will just be deletes to clean up.

It turns out there also was a non packaged symlink (created in
maintainer scripts) that had to be taken care of.

So we need another tweak which - just in the critical combination fixes
up the "state machine" to work with install/upgrade/abort but also both combinations of RM/MV as needed.
To do so if in these special "version window" in preinst after DEBHELPER we need to undo the RM (only if happened which matches that there were custom changes, but keep it in all other cases)

Finally the changes in /etc/init.d/libvirt-bin are critical throughout
the update, we don't want those to be moved. Through the combo of
renaming plus package change that would cause issues with insserv (or
need even more hacky workarounds). Therefore for that we only want to
create the .dpkg-bak and message if it was modified (unlikely anyway).

-- 
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to nova in Ubuntu.
https://bugs.launchpad.net/bugs/1694159

Title:
  Complete libvirt migration to Debian style packaging (dependencies,
  conffiles)

Status in ginger package in Ubuntu:
  Triaged
Status in kimchi package in Ubuntu:
  Triaged
Status in libvirt package in Ubuntu:
  Triaged
Status in nova package in Ubuntu:
  Confirmed
Status in ubuntu-virt package in Ubuntu:
  Fix Released
Status in uvtool package in Ubuntu:
  Confirmed
Status in virt-manager package in Ubuntu:
  Fix Released
Status in libvirt package in Debian:
  Fix Committed

Bug description:
  TL;DR:
  - post Xenial the transition was made to match Debian packaging
  - among those changes a bigger one is the split of libvirt-bin into libvirt-daemon-system, libvirt-daemon, libvirt-clients
  - libvirt-bin became a transitional package
  - on that transition not all reverse dependencies were fixed
  - also several conffiles where renamed, dropped or moved packag owning it
  We need to:
  - fix dependencies to match the new packaging so we can drop the transitional one day
  - damage on the conffiles is done, but clean up as good as possible especially with the potential yet-unaffected LTS->LTS upgrades in mind.

  Actions:
  - fix dependencies in related ubuntu only packages
  - fix conffile handling in libvirt package
  - remove kimchi and ginger from the archive (Archive admin)

  ----

  While investigating libvirt/dnsmasq interactions for bug #1694156, I
  noticed that I had redundant files under /etc/dnsmasq.d from libvirt-
  daemon-system and libvirt-bin.  Looking at the status of the libvirt-
  bin package, I see the following:

  Package: libvirt-bin
  Status: install ok installed
  Priority: extra
  Section: oldlibs
  [...]
  Conffiles:
   /etc/default/virtlockd de3684752181bda812f7bf4ef983654c obsolete
   /etc/default/libvirt-bin 619ef67a86531f89f4cf45efde87cb82 obsolete
   /etc/init/libvirt-bin.conf e946cc33fb1161ab19eddccfe526cee5 obsolete
   /etc/dnsmasq.d-available/libvirt-bin bbf7e62e130a4cb7b6db7c4260883a68 obsolete
   /etc/libvirt/libvirt-admin.conf 7c1bbeb439d79ec32ff7d18cb1364e2f obsolete
   /etc/cron.daily/libvirt-bin 21a4c092781e8119b8d5aa9d9d3d9f8b obsolete
   /etc/apparmor.d/libvirt/TEMPLATE 0d5580a22d95fc622cd5b8efe54b8757 obsolete
   /etc/dnsmasq.d/libvirt-bin bbf7e62e130a4cb7b6db7c4260883a68 obsolete

  I see that this is a transitional package, but if the libvirt-bin
  package is going to be built at all from the source, it should be
  taking care to remove the obsolete conffiles on upgrade.  This should
  be done now, even though the actual obsolescence happened some time
  ago.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ginger/+bug/1694159/+subscriptions