Re: [PATCH] autogen.sh: Restore --no-git (avoid git submodule update)

From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Pavel Hrdina <phrdina@redhat.com>
Cc: libvir-list@redhat.com, xen-devel@lists.xenproject.org,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	George Dunlap <George.Dunlap@citrix.com>
Subject: Re: [PATCH] autogen.sh: Restore --no-git (avoid git submodule update)
Date: Wed, 3 Jun 2020 11:37:08 +0100	[thread overview]
Message-ID: <20200603103708.GB2892653@redhat.com> (raw)
In-Reply-To: <20200603103109.GA11390@antique-laptop>

On Wed, Jun 03, 2020 at 12:31:09PM +0200, Pavel Hrdina wrote:
> On Tue, Jun 02, 2020 at 04:47:45PM +0100, Ian Jackson wrote:
> > Prior to 2621d48f005a "gnulib: delete all gnulib integration",
> > one could pass ./autogen.sh --no-git to prevent the libvirt build
> > system from running git submodule update.
> > 
> > This feature is needed by systems like the Xen Project CI which want
> > to explicitly control the revisions of every tree.  These will
> > typically arrange to initialise the submodules check out the right
> > version of everything, and then expect the build system not to mess
> > with it any more.
> 
> To be honest I don't understand why would anyone want to keep track of
> all submodules of all projects for any CI and update it manually every
> time the upstream project changes these submodules. Sounds like a lot
> of unnecessary work but maybe I'm missing something.

Two possible scenarios that I think are valid

 - The CI job script does not have network access
 - The CI job script sees the source dir as read-only

In both cases the CI harness would have to initialize the submodule
before runing the CI job.

I don't know if this is what Xen CI is hitting, but I think the
request is reasonable none the less.

Both Jenkins and GitLab CI have option to make the harness init
submodules prior to the job running.

> > Despite to the old documentation comments referring only to gnulib,
> > the --no-git feature is required not only because of gnulib but also
> > because of the other submodule, src/keycodemapdb.
> > 
> > (And in any case, even if it were no longer required because all the
> > submodules were removed, it ought ideally to have been retained as a
> > no-op for compaibility reasons.)
> 
> Well, we will break a lot more by switching to Meson build system where
> everyone building libvirt will have to change their scripts as it will
> not be compatible at all.

Yes, but I think that's tangential, as the two above reasons will
still apply, and Meson will cope with having submodules pre-initialized.

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