Re: [Libguestfs] Continuing the split (was: Let's split up the libguestfs git repo and tarballs)
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 :|