The sys-kernel/xen-sources 3.0.1 ebuild now depends on the xen virtual machine administrative / dom0 tools (the 'app-emulation/xen' ebuild). It didn't use to, and in my setup the domU generates it's own kernel using xen-sources. So the domU needs the kernel sources, but it certainly has no use for the administrative tools, various dom0 daemons, etc. I have no interest in the domU's having this stuff installed, so could we please remove the xen-sources' dependency on app-emulation/xen ?
The purpose of the DEPEND is to make sure the correct hypervisor is present because the hypervisor api isn't stable in the 3.0 series (http://lists.xensource.com/archives/html/xen-devel/2005-09/msg01125.html). If it wasn't there, people would version bump their kernels and expect it to work (http://lists.xensource.com/archives/html/xen-devel/2004-06/msg00062.html) Maybe you could try putting xen into /etc/portage/package.provided
> Maybe you could try putting xen into /etc/portage/package.provided Maybe I could. Or maybe we could think harder and make better ebuilds? Like, say, "if Xen ebuild is installed, THEN we check for a particular version. If Xen is not installed, we're in a DOMU, and thus we should not care for hypervisor versions (since we can't see the HV anyway, it's in a different VM)". And perform a similar check when installing the hypervisor ebuilds. That's really better, right?
The hypervisor is mapped into the address space of every guest kernel, so domUs do care about its version. Also mixing different versions of frontend and backend drivers isn't guaranteed to work unless the kernel versions are the same. Of course, there is no way to enforce that the domu and dom0 versions match given that the portage trees might not even be the same. We can't just check to see if xen is already installed - if someone emerges a number of packages the only way to enforce an ordering for portage to build them is with DEPEND. I suppose the xen-sources ebuild could have a domu USE flag that disables the xen depend.
> The hypervisor is mapped into the address space of every guest kernel, > so domUs do care about its version. As long as you upgrade your dom0 before your domu's, you should be safe. Or that's what I've heard on xen-users. > Also mixing different versions of frontend and backend drivers isn't > guaranteed to work unless the kernel versions are the same. Ok. > Of course, there is no way to enforce that the domu and dom0 versions > match given that the portage trees might not even be the same. Correct.. Would've been cool if portage worked correctly over unionfs filesystems (sharing some packages, allowing individual upgrades to others), heh. > We can't just check to see if xen is already installed - if someone emerges > a number of packages the only way to enforce an ordering for portage to build > them is with DEPEND. Ok. > I suppose the xen-sources ebuild could have a domu USE flag that disables the xen depend. Assuming that the /etc/portage/package.provided hack works, either way is fine - they're the same amount of work. What would be nice since it cannot be fixed automagically would be to document it properly. The "documenting it" part isn't hard, finding the right place to put the notice probably is, I guess.. :-) Thanks for caring!
