[Pkg-libvirt-maintainers] Bug#901940: different libvirt-lxc usage

[Christian Ehrhardt]

On Tue, Jul 17, 2018 at 12:03 PM Christian Ehrhardt <
christian.ehrhardt at canonical.com> wrote:

>
>
> On Mon, Jul 2, 2018 at 8:13 AM Guido Günther <agx at sigxcpu.org> wrote:
>
>> Hi Christian,
>> On Tue, Jun 26, 2018 at 09:18:33AM +0200, Christian Ehrhardt wrote:
>> >    > libvirt-lxc is something I want to keep in the default install
>> >    Would you be ok then to split it and make it a depends or recommends
>> for
>> >    Debian?
>> >    I could then on the Ubuntu Delta change that Dependency to a suggest
>> as we
>> >    would prefer it.
>>
>> Splitting this out is probably o.k. if we'd split out all drivers (and
>> add the necessary depends).
>
>
> 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.
> But if you want I can make one for each driver that exists in the package.
>

I was following your prior art on storage drivers which kept these in the
base package.
 usr/lib/libvirt/storage-backend/libvirt_storage_backend_disk.so
 usr/lib/libvirt/storage-backend/libvirt_storage_backend_fs.so
 usr/lib/libvirt/storage-backend/libvirt_storage_backend_iscsi.so
 usr/lib/libvirt/storage-backend/libvirt_storage_backend_logical.so
 usr/lib/libvirt/storage-backend/libvirt_storage_backend_mpath.so
 usr/lib/libvirt/storage-backend/libvirt_storage_backend_scsi.so

Currently I kept for the same reason:
usr/lib/libvirt/connection-driver/libvirt_driver_interface.so
usr/lib/libvirt/connection-driver/libvirt_driver_network.so
usr/lib/libvirt/connection-driver/libvirt_driver_nodedev.so
usr/lib/libvirt/connection-driver/libvirt_driver_nwfilter.so
usr/lib/libvirt/connection-driver/libvirt_driver_secret.so
usr/lib/libvirt/connection-driver/libvirt_driver_storage.so
usr/lib/libvirt/connection-driver/libvirt_driver_qemu.so

Of those maybe qemu can be moved also to an extra package (to be fair among
different hipervisors).
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?



> 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.
Would you need/want to file bugs for those depending on the qemu connection
as well then?

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.

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.
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.


> cu
> Christian
>
>
>> Cheers,
>>  -- Guido
>>
>
>
> --
> Christian Ehrhardt
> Software Engineer, Ubuntu Server
> Canonical Ltd
>


-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-libvirt-maintainers/attachments/20180720/48acc123/attachment.html>