The Wrapper Project

[David Disseldorp]

On Fri, 29 Nov 2013 12:15:08 -0500
Simo <simo at samba.org> wrote:

> On Fri, 2013-11-29 at 14:09 +1300, Andrew Bartlett wrote:
...
> > The way I see it is this:  Either the wrapper project is complete, and
> > so won't need updates in-tree, or we will need to manage updating the
> > build farm, user and developer instances.  Those updates will need to
> > strictly (presumably by pkg-config tests strictly checking version
> > numbers) match new revisions at exactly the same point where the
> > matching change is made in Samba.  
> 
> This is easy to do, all these projects are using git, so we can simply
> have a file with the git commit you 'standardize on' until the next
> wrapper fix. In the buildfarm you pull those git trees, then checkout to
> the 'tested' commit hash (probably a version tag anyway) and always
> build that specific version of the wrappers, until you need a newer
> version due to a fix.

What you're describing here is pretty much exactly what git submodules
offers. You have a "link" in the tree which refers to an external repo
at a specific revision (the 'tested' commit hash).

> > I'm particularly nervous about this in a 'git bisect' scenario. 
> 
> If you *really* care about bisect of samba then you really do not want
> to have changing libraries in the tree, because then during the bisect
> you *will* have too many moving parts. Not only the samba code you want
> to bisect changes, but also the wrapper libraries and many other things.
> 
> Actually if you really cared about bisect you should ask for splitting
> more stuff out into separate trees, even tests would have to move out,
> so you always use the same tests while bisecting ...
> 
> > > Last heimdal update: July 2011 (Heimdal last release was done 2012-01-11)
> > > Quick copy: 68 files changed, 6750 insertions(+), 3142 deletions(-)
> > > 
> > > Last zlib update: before 2008 (moved to lib/ in 2008)
> > > Last iniparser update: before 2010 (moved to lib/ in 2010)
> > > Last popt update: before 2010 (moved to lib/ in 2010)
> > 
> > I'm not sure what you point is here. 
> 
> The point is that we are not good at maintaining external code once you
> suck it in the tree.
> 
> Instead of embedding the whole code, we should just have a file with a
> list of upstream trees (or auto-syncing copies of those trees on
> git.samba.org) and then just put a commit hash in the build system. At
> least this integrating fixes is only a matter of changing a hash in a
> file, and people are not tempted to do one-off fixes in our forked
> version and never push it upstream.

I don't quite understand why you oppose using git submodules, as I see
it you're proposing exactly the same workflow. E.g:

ddiss at f163:~/isms> git clone git://git.samba.org/samba.git samba
...
ddiss at f163:~/isms> cd samba
ddiss at f163:~/isms/samba (master)> git submodule add git://git.samba.org/nss_wrapper.git lib/nss_wrapper_sm
...
ddiss at f163:~/isms/samba (master)> cd lib/nss_wrapper_sm
ddiss at f163:~/isms/samba/lib/nss_wrapper_sm (master)> git checkout fac1cd1f96a0f2d6d899946850847f177cfc3160
...
ddiss at f163:~/isms/samba (master)> git commit -a -m "add nss_wrapper submodule link"
...
ddiss at f163:~/isms/samba (master)> git show
commit 081fba8465b8807b3e824606267ebdcc186ba171
Author: David Disseldorp <ddiss at suse.de>
Date:   Fri Nov 29 19:20:46 2013 +0100

    add nss_wrapper submodule link

diff --git a/.gitmodules b/.gitmodules
new file mode 100644
index 0000000..18fcc20
--- /dev/null
+++ b/.gitmodules
@@ -0,0 +1,3 @@
+[submodule "lib/nss_wrapper_sm"]
+       path = lib/nss_wrapper_sm
+       url = git://git.samba.org/nss_wrapper.git
diff --git a/lib/nss_wrapper_sm b/lib/nss_wrapper_sm
new file mode 160000
index 0000000..fac1cd1
--- /dev/null
+++ b/lib/nss_wrapper_sm
@@ -0,0 +1 @@
+Subproject commit fac1cd1f96a0f2d6d899946850847f177cfc3160

Cheers, David