On Fri, Nov 29, 2019 at 12:09:47PM +0000, Richard W.M. Jones wrote:
> So, the difficulty of git submodules aside, we have now split off
> virt-v2v and virt-p2v into separate projects.
>
> I also yesterday split off the boot analysis tools into a repo which
> is likely to be rarely used and which I'll probably not bother to
> package in Fedora.
> https://github.com/libguestfs/libguestfs-analysis-tools
>
> Where do we go from here?
>
> I think one of three ways. Either:
>
> * (1) * All libguestfs tools, whether written in C or OCaml, are
> sufficiently similar to each other and so are moved into a new
> libguestfs-tools project.
>From your original mail I see this
small tools written in C
(virt-cat, virt-filesystems, virt-log, virt-ls, virt-tail,
virt-diff, virt-edit, virt-format, guestmount, virt-inspector,
virt-make-fs, virt-rescue)
guestfish
virt-alignment-scan and virt-df
virt-dib
virt-get-kernel
virt-resize
virt-sparsify
virt-v2v and virt-p2v
virt-win-reg
Most of these are fairly low level core tools just exposing some
libguestfs APIs / functionality in a slightly more convenient way
than guestfish, whether in C or OCaml.
v2v & p2v are full applications in their own right & have split
already which makes alot of sense.
The other one here that feels like an application, as opposed to
a convience wrapper, is virt-dib. So I think perhaps that one
could be a separate repo. Everything else feels fine to be bundled
as one to me.
> libguestfs.git would end up containing only the daemon, core library
> and language bindings. (Splitting out the language bindings is
> technically difficult because of their interdependence with the
> generator, and the language bindings are closely related to the API,
> so I don't see the point of splitting them out anyway.)
What about "guestfish" ? Do you consider that "core" or an
add-on tool ? To me it feels like a core thing you'd expect
to always get when you have libguestfs, so perhaps that should
be in the main repo rather than tools repo.
> Or:
>
> * (2) * Libguestfs tools in OCaml are different, and heavier-weight,
> from the C ones so we put those in a new project (named ...?) The
> libguestfs tools in C are "lightweight" in some sense so we keep those
> in libguestfs.git.
Users shouldn't know or care what language the tool uses,
so exposing an arbitrary split of tools into 2 groups based
on language feels undesirable. Doubly undesirable if there's
a chance some of those C tools will get ported to OCaml.
> * (3) * Libguestfs tools in C and OCaml are different from both
> libguestfs and each other, and so we should move them into two new
> projects (again, naming suggestions welcome).
Same thoughts as option (2).
> I'm not especially wedded to a particular approach, but I would like
> to get something going on this sooner rather than later.
To me it looks like something close to (1) is most sensible.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
_______________________________________________
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs
