The Wrapper Project

Andreas Schneider asn at samba.org
Thu Nov 28 09:22:35 MST 2013


On Thursday 28 November 2013 06:17:19 Andrew Bartlett wrote:
> One of the oddities of Samba is that we don't do that very much at all.
> We are very hesitant to rely on external free software projects, for
> better or worse.

So on day we will add glibc to our tree? :)
 
> In this case, I'm particularly hesitant about the idea of requiring it
> to be installed to permit testing, because our build farm, old, unloved
> and broken as it is, is a particularly poor environment for requiring
> the installation of external software.

You managed to install python to be able to build Samba, I don't see how other 
stuff could be much harder ... (We will come to the reason later.)

> As I've said before, in my previous work on this code, I've found and
> fixed some very subtle bugs that show up only in bizarre results in our
> make test.

Yeah, cause the stuff was simply untested. There were/are no unit tests to 
verify that the wrapper functions work as expected. Only nss_wrapper has a 
truckload of good tests from Günther. I've added more test and we have a code 
coverage of 74.9 %

http://mock.cryptomilk.org/index.php?project=nsswrapper

>  I would want to ensure we had a very strict rule as to
> exactly the version of these wrappers that we used against a specific
> version of Samba.  I think bundling these like we do popt et al is the
> best approach for now.

Why are you (an others) always come up with these lame excuses. Why don't you 
just admit that you are lazy and don't want to install any of the 3rdparty 
software.

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)

> The other thing I would miss is the ability to invoke this via CPP
> macros.  We removed smb_wrapper because we determined the LD_PRELOAD
> approach was determined not to be viable in the long term.  I guess the
> difference here is that the socket API is more limited, as because CPP
> also can't override libc calls, we have altered all the callers anyway.

What is this about now? So I should stop to get 'make test' working with the 
LD_PRELOAD wrappers?
 
> It would, even as he has left Samba development, be insightful to ask
> for Tridge's view on this, because he has more experience than anyone
> else I know on LD_PRELOAD over many years.

What do you want, that I stop working on this? Why do we dance around the 
issue here?



	-- andreas


-- 
Andreas Schneider                   GPG-ID: CC014E3D
Samba Team                             asn at samba.org
www.samba.org



More information about the samba-technical mailing list