waf: Add possibility to build with system libwbclient/libsmbclient

[Andrew Bartlett]

On Wed, 2012-04-18 at 10:37 +0200, Andreas Schneider wrote:
> On Wednesday 18 April 2012 18:08:13 you wrote:
> > Andreas,
> 
> Andrew,
> 
> > Is there any chance you could give me that chance?  My work pattern
> > gives me great flexibility for review, and in most cases it would be
> > just seeing them by e-mail over the course of my working day would work.
> > It shouldn't put you too far behind, and give me a good chance to
> > provide feedback.
> 
> that's why I contacted you yesterday. I thought you are more or less fine 
> cause you didn't say I should wait and you want to disuss this today. Sorry if 
> you did and I didn't recognize it.
> 
> > The libwbclient build is a bit interesting it seems, as we have not had
> > a proper version before.  However, Samba4-s3fs strictly depends on the
> > version 0.8 in master (for IDMAP_BOTH support, I may need to bump the
> > version to reflect my changes).  That is, it won't work with just any
> > 'version 0' libwbclient.
> > 
> > For my part, I'll update the version number in the libwbclient header,
> > but the goal Simo shared with me of using the libwbclient from 3.6
> > simply won't work.
> > 
> > On libsmbclient, I wonder if we can find a less intrusive solution to
> > your concerns.  I understand that you want to be able to build packages
> > against master's libsmbclient, but then have the user install the 3.6
> > libsmbclient, and not have the linking fail due to the upgrade to
> > version symbols.  Is that the issue, or have I misunderstood it?  It
> > seems a fairly niche use case, but perhaps I don't fully understand the
> > combinations you propose to support.
> 
> KDE, Gnome and other components link against libsmbclient and libwbclient. 
> This is for smb:// support or pam_winbind/winbind support in the login 
> managers.

OK, this is an important use case. 

> Samba4 introduced symbol versioning, which is a good thing but as Samba 3 with 
> autoconf didn't have it and all these other components link against it. I 
> can't simply replace them. Adding symbolversioning is a major change and we 
> should probably increase the so version number for that.
> 
> Alexander and I have tried to solve this issue in serveral ways but this is 
> the only way which is working.
> 
> > (I realise how this could have been a bigger issue before the dependency
> > was trimmed down to just smbget and our torture tools)
> > 
> > If the symbol versions are such a great issue, would it not be simpler
> > to just turn symbol versions back off?  I only added them recently, they
> > can be (optionally) disabled if they cause that much trouble.  For my
> > part, I'm concerned about how many additional options we both want to
> > support and test in the long term, where the use case is so far only
> > defined as transitional packaging need for Red Hat.
> 
> I think that symbol versioning is good and we shouldn't turn it off, but maybe 
> it is needed for libsmbclient and libwbclient.
> 
> If we can replace Samba3 with Samba4 then this issue is gone and we would like 
> to have symbol versioning but you can be sure that Samba3 and Samba4 will 
> coexist for some time in enterprise versions.

Where Samba3 and Samba4 co-exist, and where that is to support our
client libraries only (not running the samba binary for example), I
would recommend changing libsmbclient, libnet, libwbclient and other
libraries to private libraries in the wscript_build files.  That way, we
won't use and will not interfere with the system libs of the same names
and namespaces, but we can still depend on them where that is useful.

> > I realise that Red Hat has unique packaging concerns that have not come
> > up for the other vendors already packaging Samba4, and that you have are
> > trying to address these in a limited timeframe.  Just as with the MIT
> > krb5 issue, I am more than willing to work constructively with you on
> > these.  The best way I can do that is if I get a chance to discuss the
> > changes you want, so we can find the best outcome all-round.
> 
> I will contact you as I did yesterday in future too. Just tell me to discuss 
> this in detail the next day if you don't have time and we're fine :)

Thanks.  I'll certainly to be more clear in future.

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org