I tried to play with minikube-0.28.0-r1 and the build failed (see attached log), indicating that libvirt was not found. Apparently minikube runs in a VM and requires libvirt, but the ebuild does declare such a dependency. It probably should. Reproducible: Always Steps to Reproduce: 1. have no VM support installed 2. emerge minikube 3. fail! Actual Results: Build failure; see attached log Expected Results: Correct build with required dependencies.
Created attachment 538282 [details] build log for failed minikube
(In reply to Holger Hoffstätte from comment #0) > ebuild does declare such a dependency. It probably should. Obviously "..the ebuild does NOT declare..".
FWIW manually emerging libvirt (pulling in qemu) let the build succeed.
Apologies for talking to myself here, but this is worse than I thought. The simplest way to sort this mess is probably: - prevent building docker-machine-driver-kvm2 (if possible), and therefore not depend on libvirt/qemu etc. - depend on virtualbox and make that the recommended out-of-the-box default. This will work with the least amount of fighting; I successfully connected to the dashboard after building virtualbox as well. Also a dependency on vbox doesn't sound so bad considering that minikube in no-vm mode doesn't even work on Gentoo/OpenRc because it apparently has systemd commands hardcoded in (when starting kubeadm/kubelet), and this mode is likely going away soon anyway.
FWIW I've looked into the ebuild and have started updating it with USE- controlled build/install bits, defaulting to virtualbox but retaining kvm support via libvirt (disabled by default). I'll post an ebuild patch after more testing.
Created attachment 538906 [details, diff] Patch to add vbox dependency by default This patch adds vbox (or vbox-bin) by default and makes kvm (libvirt/qemu/etc.) optional. This should provide a better out-of-the-box experience. I think I read that +kvm might also need libvirt with +virt-network, but I cannot test this at the moment; details welcome.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d31542deed327486c3d5dce45e8b7bb663ee1166 commit d31542deed327486c3d5dce45e8b7bb663ee1166 Author: Manuel Rüger <mrueg@gentoo.org> AuthorDate: 2018-07-18 18:38:40 +0000 Commit: Manuel Rüger <mrueg@gentoo.org> CommitDate: 2018-07-18 18:39:38 +0000 sys-cluster/minikube: Version bump to 0.28.1 Fix dependency on libvirt as provided by Holger Hoffstätte in bug 660304 Closes: https://bugs.gentoo.org/660304 Package-Manager: Portage-2.3.43, Repoman-2.3.10 sys-cluster/minikube/Manifest | 1 + sys-cluster/minikube/metadata.xml | 3 ++ sys-cluster/minikube/minikube-0.28.1.ebuild | 45 +++++++++++++++++++++++++++++ 3 files changed, 49 insertions(+)
I've added a dep on libvirt, thanks I missed that. In terms of virtualbox, I'm not sure how to treat optional RDEPENDs here (which is a generic gentoo issue).
The point of the virtualbox flag was to provide an out-of-the-box installation that doesn't shit the bed, which it does if you don't have vbox installed and do a "minikube start" for the first time - it will copy downloaded kube* binaries to /usr/bin, create a broken "VM"/kubeadm that doesn't start (because hardcoded systemd) and stays that way until explicitly deleted again. I didn't understand half of what was going on until I dug into the !"§$% minikube sources! If you really don't want to add virtualbox as RDEPEND (which wasn't optional?) please at least add a loud and clear postinstall warning which says that minikube won't work ootb and that virtualbox is the recommended and easiest default VM provider.
