Bug 1012198

 libvirt-client                  x86_64 1.1.2-3.fc20      updates-testing 5.4 M

This has a 1.5 meg ChangeLog.gz, and 15 megs of translations. That seems a bit large...

 ceph-libs                       x86_64 0.67.3-1.fc20     updates-testing 1.7 M
Also kind of large, does libvirt really depend on Ceph?

(In reply to Alexander Larsson from comment #1)
>  libvirt-client                  x86_64 1.1.2-3.fc20      updates-testing
> 5.4 M
> 
> This has a 1.5 meg ChangeLog.gz, and 15 megs of translations. That seems a
> bit large...

The changelog is moved into -devel in current builds so won't impact. There's not really anything we can do about translations unless we want to screw over non-english speakers.

> 
>  ceph-libs                       x86_64 0.67.3-1.fc20     updates-testing
> 1.7 M
> Also kind of large, does libvirt really depend on Ceph?

Yes, the storage management features use ceph.

Update: something is now pulling in Avahi. I *really* don't want avahi on the cloud image.

avahi daemon, or avahi libs?

libvirt only depends on avahi-libs, so if something is pulling in the daemon, it isn't libvirt directly.

avahi-libs now pulls in avahi daemon -- that's bug #913168, apparently.

Oh actually, I just noticed you are installing the high level libvirt lxc package:

> Installing:
>   libvirt-daemon-lxc              x86_64 1.1.2-3.fc20      updates-testing  34 

At the cost of breaking many libvirt APIs you could switch to installing the finer grained package  'libvirt-daemon-driver-lxc'. That would pull in just the lxc hypervisor APIs, which is closer in terms of functionality to the lxc tools. 

Of course if the app using libvirt needs to use non-hypervisor APIs, you're still doomed because it'll need to pull in the other libvirt-daemon-driver-* packages anyway.  It also might lead to bug reports from users who find that various parts of libvirt are non-functional, so not sure whether its a good idea for the cloud image or not really.

I was excited about that suggestion for a minute, but it turns out that if I just do `yum install libvirt-daemon-driver-lxc`, everything is pulled in except

  hwdata
  libpciaccess
  libvirt-daemon-driver-interface
  libvirt-daemon-driver-nodedev
  libvirt-daemon-driver-nwfilter
  libvirt-daemon-driver-secret
  libvirt-daemon-driver-storage
  libvirt-daemon-lxc

So basically it looks like everything is pulled in _except_ the APIs. This saves about 5MB -- two megabytes compressed -- and doesn't really address the security-respin concern. So I think we're better off with the higher-level unless we can somehow make that have a significant impact.

Thanks for the idea, though!

(In reply to Matthew Miller from comment #8)
> I was excited about that suggestion for a minute, but it turns out that if I
> just do `yum install libvirt-daemon-driver-lxc`, everything is pulled in
> except
> 
>   hwdata
>   libpciaccess
>   libvirt-daemon-driver-interface
>   libvirt-daemon-driver-nodedev
>   libvirt-daemon-driver-nwfilter
>   libvirt-daemon-driver-secret
>   libvirt-daemon-driver-storage
>   libvirt-daemon-lxc
> 
> So basically it looks like everything is pulled in _except_ the APIs. This
> saves about 5MB -- two megabytes compressed -- and doesn't really address
> the security-respin concern. So I think we're better off with the
> higher-level unless we can somehow make that have a significant impact.

Smells like something is wrong there then. All those storage related deps like ceph/gluster/etc should only be required by the libvirt-daemon-driver-storage sub-RPM.

(In reply to Daniel Berrange from comment #9)
> Smells like something is wrong there then. All those storage related deps
> like ceph/gluster/etc should only be required by the
> libvirt-daemon-driver-storage sub-RPM.

libvirt-daemon-driver-lxc requires libvirt-daemon, and then that pulls in all the other stuff.

Ok, that definitely sounds broken then. The libvirt-daemon package itself should be pretty minimal on deps since it only really contains RPC code.

Created attachment 817058 [details]
Remove bogus deps from libvirt-daemon RPM

This patch removes the many bogus deps from the libvirt-daemon RPM, pushing them down to the libvirt-daemon-driver-XXXX RPMs which actually require them.

On a Fedora 19 host, I installed a minimal container using

 # yum -y --releasever=19 --nogpg --installroot=/var/lib/libvirt/filesystems/libvirtsize1 \
          --disablerepo='*' --enablerepo=fedora install \
          systemd passwd yum fedora-release vim-minimal openssh-server procps-ng

And then installed just 'libvirt-daemon-driver-lxc' - this pulls in libvirt-daemon-driver-network, libvirt-daemon and libvirt-client.

With the existing packaging I see this size usage

# du -h -c -s /var/lib/libvirt/filesystems/libvirtsize1
453M	/var/lib/libvirt/filesystems/libvirtsize1
453M	total

With the patch applied, we save 41 MB:

# du -h -c -s /var/lib/libvirt/filesystems/libvirtsize2
412M	/var/lib/libvirt/filesystems/libvirtsize2
412M	total

The following packages are now, no longer required in the minimal install

augeas-libs-1.0.0-2.fc19.x86_64
boost-system-1.53.0-6.fc19.x86_64
boost-thread-1.53.0-6.fc19.x86_64
bzip2-1.0.6-8.fc19.x86_64
ceph-libs-0.56.4-1.fc19.x86_64
corosync-2.3.0-3.fc19.x86_64
corosynclib-2.3.0-3.fc19.x86_64
cryptopp-5.6.2-2.fc19.x86_64
device-mapper-event-1.02.77-9.fc19.x86_64
device-mapper-event-libs-1.02.77-9.fc19.x86_64
device-mapper-persistent-data-0.1.4-3.fc19.x86_64
e2fsprogs-libs-1.42.7-2.fc19.x86_64
ebtables-2.0.10-8.fc19.x86_64
fuse-2.9.2-3.fc19.x86_64
glusterfs-3.4.0-0.5.beta2.fc19.x86_64
glusterfs-api-3.4.0-0.5.beta2.fc19.x86_64
glusterfs-fuse-3.4.0-0.5.beta2.fc19.x86_64
iscsi-initiator-utils-6.2.0.873-6.fc19.x86_64
keyutils-1.5.5-4.fc19.x86_64
leveldb-1.9.0-1.fc19.x86_64
libaio-0.3.109-7.fc19.x86_64
libibverbs-1.1.6-6.fc19.x86_64
libiscsi-1.7.0-4.fc19.x86_64
libnfsidmap-0.25-5.fc19.x86_64
libqb-0.14.4-2.fc19.x86_64
librdmacm-1.0.17-1.fc19.x86_64
libtirpc-0.2.3-2.fc19.x86_64
libxslt-1.1.28-3.fc19.x86_64
lvm2-2.02.98-9.fc19.x86_64
lvm2-libs-2.02.98-9.fc19.x86_64
lzo-2.06-4.fc19.x86_64
lzop-1.03-8.fc19.x86_64
netcf-libs-0.2.3-4.fc19.x86_64
net-snmp-libs-5.7.2-11.fc19.x86_64
nfs-utils-1.2.8-2.0.fc19.x86_64
qemu-img-1.4.2-3.fc19.x86_64
quota-4.01-6.fc19.x86_64
quota-nls-4.01-6.fc19.noarch
rpcbind-0.2.0-21.fc19.x86_64
sheepdog-0.3.0-4.fc19.x86_64
snappy-1.1.0-1.fc19.x86_64
tcp_wrappers-7.6-73.fc19.x86_64
which-2.20-5.fc19.x86_64
xz-5.1.2-4alpha.fc19.x86_64


I don't think we can get much smaller than this without either major code changes to libvirt, or improvements to RPM to allow exclusion of things like translations without breaking upgrades

Oh, note that since I used F19 for this test, it still has the 1.5 MB changelog.gz file present, that is gone in rawhide/f20.

libvirt-1.1.3.1-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/libvirt-1.1.3.1-1.fc20

Package libvirt-1.1.3.1-1.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libvirt-1.1.3.1-1.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-20869/libvirt-1.1.3.1-1.fc20
then log in and leave karma (feedback).

libvirt-1.1.3.1-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.