<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Jul 17, 2018 at 12:03 PM Christian Ehrhardt <<a href="mailto:christian.ehrhardt@canonical.com">christian.ehrhardt@canonical.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Jul 2, 2018 at 8:13 AM Guido Günther <<a href="mailto:agx@sigxcpu.org" target="_blank">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 Christian,<br>
On Tue, Jun 26, 2018 at 09:18:33AM +0200, Christian Ehrhardt wrote:<br>
>    > libvirt-lxc is something I want to keep in the default install<br>
>    Would you be ok then to split it and make it a depends or recommends for<br>
>    Debian?<br>
>    I could then on the Ubuntu Delta change that Dependency to a suggest as we<br>
>    would prefer it.<br>
<br>
Splitting this out is probably o.k. if we'd split out all drivers (and<br>
add the necessary depends).</blockquote><div><br></div><div><span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">I'd be ok to split the remaining drivers if you want me to do so, I was not taking out the most essential ones just as you have done for storage.</span></div><div><span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">But if you want I can make one for each driver that exists in the package.</span></div></div></div></blockquote><div><br></div><div>I was following your prior art on storage drivers which kept these in the base package.<br> usr/lib/libvirt/storage-backend/libvirt_storage_backend_disk.so<br> usr/lib/libvirt/storage-backend/libvirt_storage_backend_fs.so<br> usr/lib/libvirt/storage-backend/libvirt_storage_backend_iscsi.so<br> usr/lib/libvirt/storage-backend/libvirt_storage_backend_logical.so<br> usr/lib/libvirt/storage-backend/libvirt_storage_backend_mpath.so<br> usr/lib/libvirt/storage-backend/libvirt_storage_backend_scsi.so</div><div><br></div><div>Currently I kept for the same reason:</div><div><span style="font-family:monospace"><span style="color:rgb(0,0,0);background-color:rgb(255,255,255)">usr/lib/libvirt/connection-driver/libvirt_driver_interface.so
</span><br>usr/lib/libvirt/connection-driver/libvirt_driver_network.so
<br>usr/lib/libvirt/connection-driver/libvirt_driver_nodedev.so
<br>usr/lib/libvirt/connection-driver/libvirt_driver_nwfilter.so
<br>usr/lib/libvirt/connection-driver/libvirt_driver_secret.so
<br>usr/lib/libvirt/connection-driver/libvirt_driver_storage.so
<br>usr/lib/libvirt/connection-driver/libvirt_driver_qemu.so<br></span><br></div><div>Of those maybe qemu can be moved also to an extra package (to be fair among different hipervisors).</div><div>But all other connections are internal and I'd keep them in the base package.</div><div><br></div><div>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?</div><div><br></div><div>  <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This also needs a NEWS entry so people are<br>
aware that this has changed</blockquote><div><br></div><div>Sure, I can do so in a v2 as well</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">as well as bugs against all reverse<br>
dependencies to inform them that they might need to depend on a<br>
different package.</blockquote><div><br></div><div>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.</div></div></div></blockquote><div> </div><div>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.</div><div>Would you need/want to file bugs for those depending on the qemu connection as well then?</div><div><br></div><div>Because looking at all Dependencies on src:libvirt there are only a few affected by the others IMHO.</div><div>The connections affected would be for lxc, uml, vbox and xen.</div><div>As I said you can pick your preference which of these to move from suggest to Recommends or higher - you mentioned lxc for example.</div><div><br></div><div>Ignoring the bindings as they will not need the connection .so I looked at</div><div><span style="font-family:monospace"><span style="color:rgb(0,0,0);background-color:rgb(255,255,255)">$ apt-cache rdepends --no-suggests --no-conflicts --no-breaks --no-replaces --no-enhances libvirt-daemon libvirt-</span><br>daemon-system libvirt0</span></div><br>In that IMHO only collectd and xenwatch might be affected and would need a bug filed to consider changing dependencies.<br>Or would you want a mass bug to all of them, just in case?<div><br></div><div>Since also only xen gives us an immediate gain in dependencies/install size.</div><div>How about having all but xen as recommends, and xen as suggests.</div><div>That limits a lot what would be affected.</div><div><br></div><div>I can in Ubuntu easily switch -lxc (which I want to loose, but being no benefit to you) from a recommends to a suggest.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Is this worth the trouble for getting rid of a libxen<br>
dependency?<br></blockquote><div><br></div><div>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).</div><div>I'm a bit short on time atm being here a few days in between PTO, I'll report back here later on.<br></div></div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>cu</div><div>Christian</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Cheers,<br>
 -- Guido<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="m_-930123077818426029gmail_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></div>
</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></div>