waf: Add possibility to build with system libwbclient/libsmbclient

[Andreas Schneider]

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.

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.

> 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 :)


	-- andreas

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