[Libguestfs] 1.39 proposal: Let's split up the libguestfs git repo and tarballs

[Richard W.M. Jones]

On Mon, Jul 01, 2019 at 06:10:48PM +0200, Pino Toscano wrote:
> On Monday, 10 June 2019 17:35:52 CEST Richard W.M. Jones wrote:
> > So while I'm not a massive fan of git submodules, now that I have used
> > them a few times with riscv stuff, they do solve a certain problem as
> > long as they are managed carefully.  I think the common code and the
> > generator are cases where a submodule or two would work.
> 
> TBH I've always found submodules tricky and problematic to use:
> - they are fixed to a certain revision (so no way to dynamically follow
>   the branch of another repo)
> - the URL is the same for all the users, meaning you cannot reuse the
>   same authenticated/secure protocols that your repo has
> - they create a certain burden when switching to a tag/branch/commit
>   whose revision of a submodule is different than what is at the current
>   branch
> - even more problematic when switching commit, and in the old commit
>   a subdirectory is a real directory while in the latest HEAD is a
>   submodule (or viceversa)

I mean, I don't disagree with any of this :-)

For riscv we pinned Linux kernel and various toolchains at precise
commits, and then only moved those forwards as we tested new
combinations.

Anyhow, whatever works.

> > Does this mean we need to move immediately to a submodule if just
> > splitting virt-p2v, or copy code as you suggest?  Maybe not, because
> > you can imagine for just this project copying the code needed from the
> > common/ directory, and creating a new "mini-generator" for the project
> > which handles the little bits that need to be generated in virt-p2v.
> 
> I'm actually solving in a different way, i.e. avoiding altogether the
> generator for p2v stuff.

Hmm.  There are parts of the current generator that apply to virt-p2v.

Can we split those parts of the generator out to have a new generator
that only applies to p2v?  I find the generated config stuff useful,
and in fact have a non-upstream patch to enhance it some more.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top