The Wrapper Project
ddiss at suse.de
Fri Nov 29 11:31:07 MST 2013
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
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
@@ -0,0 +1,3 @@
+ 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
@@ -0,0 +1 @@
+Subproject commit fac1cd1f96a0f2d6d899946850847f177cfc3160
More information about the samba-technical