libvirt0 breaks libvirt-bin compiled from sources

[César Morgan]

The package libvirt0-1.3.1-1ubuntu10.10 included in Ubuntu 16.04 breaks libvirt-bin 3.4+ compiled from official libvirt sources. It should be replaced by a dummy package.
I've tested this with libvirt 3.4 and libvirt 3.5, both versions will fail if libvirt0 is installed.

To reproduce:
1. Install qemu-kvm package, and virt-manager with all recommended dependencies. libvirt0 gets automatically installed.
2. Download, compile and install libvirt 3.4+ from the official sources.
3. attempt to restart the libvirtd service.

Expected behavior:
The service should have worked.

What really happened:
The service failed to start without any useful information about why.

Temporary workaround:
1. forcefully uninstall libvirt0 ignoring dependencies: "dpkg -r --ignore-depends=libvirt0 libvirt0"
2. reinstall the compiled version of libvirt (for good measure)
3. For each update: do "apt-get -f install" first, do the updates and uninstall libvirt0 again.

Everything seems to be working fine without libvirt0, except of course, APT, which wants to fix the dependency issue.

Suggested fix:
Make libvirt0 a metapackage, so it installs an updated version of libvirt. 3.4.0 is stable, and there's no special requirements to create a usable .deb package.

[Christian Ehrhardt  (paelzer)]

Hi Cesar,
thank you for your report - although I must admit I need to understand your point a bit better.
Here my initial check of your case, please comment on it so we find if/what action one should take.

First of all - what is libvirt0 - it is the collection of .so files, the actual library that libvirt is.
That means files like:
  /usr/lib/x86_64-linux-gnu/libvirt.so.0

Furthermore lets check why it was installed for you, you listed "qemu-kvm package, and virt-manager with all recommended dependencies":
- qemu-kvm you can install even with recommends it will not bring libvirt in
- virt-manager "depends" on the python-libvirt it was built for and that depends on the matching
  libvirt0 then.

I'd expect a self built/installed libvirt to conflict with the packaged one anyway.
The self build one likely picks up the .so files from the packaged version.
When you start your custom built libvirtd you'd need to ensure it does not pick up those.

But I mist admit - and I beg your pardon if I overlook something - I don't consider this an issue of the packaging - libs conflict with the same libs in other paths, I miss the special part.

If we would make libvirt0 a metapackage we would just need a different package to carry the .so's and that would conflict with your manual built libvirt.

My personal way to go in your case would be to install all from the archive as usual; Then stop and disable the libvirt service. And finally for your custom build libvirt make sure it picks up only its own libraries which should fix your conflict.
That implies that the packaged virt-manager can work with the python-libvirt that you have to provide it from your manual build then.

[César Morgan (xds-xps-ivx)]

Thank you for your reply.
Well, I did several tests of having a clean system, installing only the libvirt0 package and then compiling and installing libvirt-bin with --prefix=/usr --sysconfdir=/etc --localstatedir=/var, and libvirt0 still makes my compiled version crash. Did I miss a directory?

That particular question might be my point. Maybe I forgot to replace files from a particular directory? My guess would be something to do with /usr/lib/x86_64-linux-gnu...

Still, if this doesn't really qualify as a bug, it might still be useful information for the next Ubuntu release, so maybe we can include an updated libvirt-bin package on the repositories.

My problem really came from the need to use an update version of the library along with qemu-kvm and virt-manager, the latter of which, indirectly depends on libvirt0. I could just uninstall it with dpkg, but then I will need to reinstall it in order for apt to be able to upgrade packages.

I took the liberty of trying out a dummy libvirt0 package I made, and so far, everything works.

[Christian Ehrhardt  (paelzer)]

Thanks for your reply Cesar.

Yeah I - and others - really appreciate the reporting.
About the libvirt-bin package - that is only a transitional these days and will be dropped after 18.04 (we need to wait to catch all potential upgrade paths).

You configure suggests that you expect it to override all that the packages bring in the main system directories.
In case you debug it again - I'd expect that when you run "ldd" against the libvirt binaries you built your own that you will find some of the library resolutions still pointing at the packaged versions.

I'm happy that for now you seem to get along with a dummy.

If you want to take a "beta test" you might try [1].
I just refreshed that as it was not working for some years.
And it might have a random number of issues being so "fresh".
But OTOH it might give you just what you need for now - a fresh and very recent libvirt.
Let me know if you have feedback on that one.

[1]: https://launchpad.net/~ubuntu-virt/+archive/ubuntu/virt-daily-upstream

[Launchpad Janitor (janitor)]

[Expired for libvirt (Ubuntu) because there has been no activity for 60 days.]