The Wrapper Project

Stefan (metze) Metzmacher metze at
Fri Nov 29 11:51:15 MST 2013

Hi David,

>> 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
>> 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:// samba
> ...
> ddiss at f163:~/isms> cd samba
> ddiss at f163:~/isms/samba (master)> git submodule add 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>
> 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://
> 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

When you would push that and then I'd just do a

mkdir samba-work
cd samba-work
git init
git remote add origin git://
git remote update
then disconnect from the network. Would I be able to do

git checkout 081fba8465b8807b3e824606267ebdcc186ba171

without network access and have everthing I need?


More information about the samba-technical mailing list