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