[Bug 1694159] Re: libvirt-bin dropped conffiles but never cleaned them up on disk
ChristianEhrhardt
1694159 at bugs.launchpad.net
Tue May 30 14:27:27 UTC 2017
I was summarizing the cases we have into three categories:
Old Package A
New Packages B, C
Certain kinds of conffile transitions that forgot to properly mv_conffile/rm_conffile
Naturally new installs are fine, but we have upgraded systems facing the following cases.
Syntax
<PKG>-<Conffile> -> change that happened
1. A-1 -> no more needed
2. A-2 -> B-2 "same content" but different filename, upgraded systems have A-2 && B-2 on disk
3. A-3 -> B-3, B-3 is somewhat related, but of different content than A-3 (e.g. needed different defaults)
I think the following is the right action:
1. rm_conffile
2. Correct would have been mv_conffile initially, but it was not what happened.
Now we have multiple types of users:
2.1 had changes to A-2 that are no more active since yakkety or utopic - if it wasn't a problem so far it won't be too much of a problem to remove it now. (rm_conffile)
2.2 had no changes to A-2, the defaults of B-2 should apply (rm_conffile)
2.3 already have changes to B-2, whatever is in A-2 should not break that (rm_conffile)
2.4 had changes to A-2 and now have changes to B-2. Some special case of 2.1, but essentially they are not broken or broken since yakkety so wile not nice (rm_conffile)
3. Correct would have been mv_conffile initially, but it was not what happened.
Even less than with #2 we can retain the old content, since it would break things.
All arguments of #2 apply plus the "need" to get the old defaults changed (rm_conffile)
I wonder if for #2 and less likely for #3 we would want some magic of
"If A-2 was not the original A-2, then take over the content to B-2 IFF
B-2 is the default B-2". Yet I think in this case the upgrade would be a
behavior change that potentially is not wanted. If users "cared" about
their change to A-2 they already suffered and implemented it in B-2.
Discussed with Rbasak and we agreed while one could try to do some magic, the chance to do it wrong is bigger than the gain.
Also we have two kinds of users, those who are already broken and we "can't safe", and OTOH those who will go LTS->LTS which we can actually save.
So for those who will do LTS->LTS (Which later also applies to Ubuntu Cloud Archive if you go Xenial -> >=Pike) - there we might be able to improve the situation.
Because it turned out while some of those files were just forgotten - others should have been handled but that didn't work.
libvirt-daemon-system.maintscript has entries for some of the files, but that did not work.
I'm now debugging into that and maybe we will end up with:
1. rm-conffiles if coming from the broken releases (versions in yakkety/zesty)
2. mv_conffiles for those coming from Xenial
Debugging deeper into this now which will take a while ...
** Summary changed:
- libvirt-bin dropped conffiles but never cleaned them up on disk
+ Complete libvirt migration to Debian style packaging (dependencies, conffiles)
** Description changed:
+ 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.
+
+ ----
+
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
+ /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.
--
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:
New
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.
----
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
More information about the Ubuntu-openstack-bugs
mailing list