<div dir="ltr">Hi,<div>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.</div><div><br></div><div>Just coming back from PTO and finding way too much more urgent todos than this where I just want to make it better :-/</div><div>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.</div><div><br></div><div>I'll leave this in my inbox for probably way too long to come back to it one day.</div><div>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.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jul 20, 2018 at 9:26 AM Guido Günther <<a href="mailto:agx@sigxcpu.org">agx@sigxcpu.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
On Fri, Jul 20, 2018 at 08:29:38AM +0200, Christian Ehrhardt wrote:<br>
>    But all other connections are internal and I'd keep them in the base<br>
>    package.<br>
>    So would you be ok to break out _qemu.so on top on what I suggested and<br>
>    leave the others - or do you want more?<br>
<br>
Yes, please break out qemu as well.<br>
<br>
>        This also needs a NEWS entry so people are<br>
>        aware that this has changed<br>
> <br>
>      Sure, I can do so in a v2 as well<br>
>       <br>
> <br>
>        as well as bugs against all reverse<br>
>        dependencies to inform them that they might need to depend on a<br>
>        different package.<br>
> <br>
>      If we keep all but Xen as Depends, and only Xen to a Recommends/Suggests<br>
>      depending on your judgement that should not be too much affected<br>
>      packages.<br>
> <br>
>     <br>
>    Even if breaking it into an extra package I'd keep the _qemu driver as<br>
>    Depends or "at least" Recommends - let me know if you prefer one over the<br>
>    other.<br>
<br>
Depends is good here.<br>
<br>
>    Would you need/want to file bugs for those depending on the qemu<br>
>    connection as well then?<br>
<br>
No that's not needed.<br>
<br>
>    Because looking at all Dependencies on src:libvirt there are only a few<br>
>    affected by the others IMHO.<br>
>    The connections affected would be for lxc, uml, vbox and xen.<br>
>    As I said you can pick your preference which of these to move from suggest<br>
>    to Recommends or higher - you mentioned lxc for example.<br>
<br>
uml, vbox and xen are fine as suggests. lxc should be recommends and<br>
qemu depends.<br>
<br>
>    Ignoring the bindings as they will not need the connection .so I looked at<br>
>    $ apt-cache rdepends --no-suggests --no-conflicts --no-breaks<br>
>    --no-replaces --no-enhances libvirt-daemon libvirt-<br>
>    daemon-system libvirt0<br>
>    In that IMHO only collectd and xenwatch might be affected and would need a<br>
>    bug filed to consider changing dependencies.<br>
<br>
I'm unsure about nova-compute-lxc. I would expect it to use plain lxc<br>
but it depends on libvirt-daemon-system. Better safe than sorry.<br>
<br>
>    Or would you want a mass bug to all of them, just in case?<br>
>    Since also only xen gives us an immediate gain in dependencies/install<br>
>    size.<br>
>    How about having all but xen as recommends, and xen as suggests.<br>
>    That limits a lot what would be affected.<br>
>    I can in Ubuntu easily switch -lxc (which I want to loose, but being no<br>
>    benefit to you) from a recommends to a suggest.<br>
>     <br>
> <br>
>        Is this worth the trouble for getting rid of a libxen<br>
>        dependency?<br>
> <br>
>      I'm tempted to say yes, but let me check how many reasonable reverse<br>
>      dependencies that are out there that might be affected (how many of them<br>
>      are Xen related/consuming).<br>
>      I'm a bit short on time atm being here a few days in between PTO, I'll<br>
>      report back here later on.<br>
> <br>
>    I'm off a week now, take your time to think about it and let me know if it<br>
>    is worth for me providing a V2 with the changes discussed above.<br>
<br>
See above. A tested patch would be great.<br>
Cheers,<br>
 -- Guido<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><span style="color:rgb(136,136,136);font-size:12.8px">Christian Ehrhardt</span><div style="color:rgb(136,136,136);font-size:12.8px">Software Engineer, Ubuntu Server</div><div style="color:rgb(136,136,136);font-size:12.8px">Canonical Ltd</div></div></div></div></div>