On Mon, Jul 30, 2018 at 08:44:01AM +0200, Christian Ehrhardt wrote: > Hi, > thanks for the reply Guido all sounds good to me, and I'll take a look "at > some point" (tm) - but I have to give up on this for now.
Too bad. > Just coming back from PTO and finding way too much more urgent todos than > this where I just want to make it better :-/ > Also other changes to qemu that I'd need to happen to achieve my long term > goal around getting rid of more xen dependencies (e.g. from qemu) won't > happen anytime soon either. > I'll leave this in my inbox for probably way too long to come back to it > one day. > But from the Debian bugs POV feel free to close it for now for a better > overview if you want - we can re-open when I come back to it one day. > On Fri, Jul 20, 2018 at 9:26 AM Guido Günther <[1]a...@sigxcpu.org> wrote: Lets leave that open maybe someone else wants to step in. -- Guido > > Hi, > On Fri, Jul 20, 2018 at 08:29:38AM +0200, Christian Ehrhardt wrote: > > But all other connections are internal and I'd keep them in the > base > > package. > > So would you be ok to break out _qemu.so on top on what I suggested > and > > leave the others - or do you want more? > > Yes, please break out qemu as well. > > > This also needs a NEWS entry so people are > > aware that this has changed > > > > Sure, I can do so in a v2 as well > > > > > > as well as bugs against all reverse > > dependencies to inform them that they might need to depend on a > > different package. > > > > If we keep all but Xen as Depends, and only Xen to a > Recommends/Suggests > > depending on your judgement that should not be too much affected > > packages. > > > > > > Even if breaking it into an extra package I'd keep the _qemu driver > as > > Depends or "at least" Recommends - let me know if you prefer one > over the > > other. > > Depends is good here. > > > Would you need/want to file bugs for those depending on the qemu > > connection as well then? > > No that's not needed. > > > Because looking at all Dependencies on src:libvirt there are only a > few > > affected by the others IMHO. > > The connections affected would be for lxc, uml, vbox and xen. > > As I said you can pick your preference which of these to move from > suggest > > to Recommends or higher - you mentioned lxc for example. > > uml, vbox and xen are fine as suggests. lxc should be recommends and > qemu depends. > > > Ignoring the bindings as they will not need the connection .so I > looked at > > $ apt-cache rdepends --no-suggests --no-conflicts --no-breaks > > --no-replaces --no-enhances libvirt-daemon libvirt- > > daemon-system libvirt0 > > In that IMHO only collectd and xenwatch might be affected and would > need a > > bug filed to consider changing dependencies. > > I'm unsure about nova-compute-lxc. I would expect it to use plain lxc > but it depends on libvirt-daemon-system. Better safe than sorry. > > > Or would you want a mass bug to all of them, just in case? > > Since also only xen gives us an immediate gain in > dependencies/install > > size. > > How about having all but xen as recommends, and xen as suggests. > > That limits a lot what would be affected. > > I can in Ubuntu easily switch -lxc (which I want to loose, but > being no > > benefit to you) from a recommends to a suggest. > > > > > > Is this worth the trouble for getting rid of a libxen > > dependency? > > > > I'm tempted to say yes, but let me check how many reasonable > reverse > > dependencies that are out there that might be affected (how many > of them > > are Xen related/consuming). > > I'm a bit short on time atm being here a few days in between PTO, > I'll > > report back here later on. > > > > I'm off a week now, take your time to think about it and let me > know if it > > is worth for me providing a V2 with the changes discussed above. > > See above. A tested patch would be great. > Cheers, > -- Guido > > -- > Christian Ehrhardt > Software Engineer, Ubuntu Server > Canonical Ltd > > References > > Visible links > 1. mailto:a...@sigxcpu.org
