On Mon, 2016-02-15 at 17:20 +0000, Daniel Firth wrote:
I got fed up with trove submodules being difficult to work with, so
made this RFC:
This seemed to me to be the optimal way to change the schema, but
like to finish this in such a way that will make everyone happy.
does mean it will refuse to build any chunk that doesn't have a
complete dictionary of submodule and nested submodule translations
the strata morphology, but that seems like the sensible thing to me.
The git submodules approach is one technique (currently the most
popular) for assembling some sources into a directory structure so that
a given package is ready to build.
This approach looks like it takes care of the git submodule problem
Would it be a far stretch to extend this work to also cover/consider
cases where other techniques were employed to achieve the same ?
There are some edge cases where an upstream has opted to call wget in
their build scripts in order to download some data package required for
the build, we have worked around this in various ways; the
baserock/1.2.91 branch of libpinyin is a prime example of this. The
GLEW upstream also has a wget requirement when building from git, which
is why we opted to lorry the tarball instead.
I'm pretty sure that Richard Maw already proposed something similar to
this (or perhaps I'm thinking of an IRC discussion only)... but to
illustrate the idea:
In comparison to your ansible example:
We could have:
ref: <SHA1 Key here>
The 'ref' here could be optional, and if not specified it could be
assumed to be a git submodule, it would have to be specified explicitly
when pulling in any sources that are not a git submodule.
In our discussion that I vaguely recall, we had also called submodules
'repos' instead, and deprecated the existing 'ref'/'repo'
the chunk, so that assembling sources for a chunk build was an
iterative process over all of the specified 'repos' (if a deprecated
'ref'/'repo' pair is specified, it would be considered as the first
element of the 'repos' array).
I think this already discussed approach looks remarkably similar to
what you are proposing, except that it is not limited to only cover git