unversioned public libraries in Samba (was: Re: ntdb in Samba?)

[Andrew Bartlett]

On Sat, 2015-03-14 at 15:07 +0100, Volker Lendecke wrote:
> On Sat, Mar 14, 2015 at 01:14:31PM +0100, Michael Adam wrote:
> > On 2015-03-13 at 20:51 +0100, Volker Lendecke wrote:
> > > On Fri, Mar 13, 2015 at 06:01:42PM +0100, Michael Adam wrote:
> > > > Excellent idea.
> > > > 
> > > > I also find it regrettable that the proposed git tree has been
> > > > withdrawn so fast..
> > > 
> > > My point is that we need a better communication strategy about which
> > > pieces of Samba we want to take the liberty to change without notice
> > > and which pieces we stick to.
> > 
> > That is easy (and has been stated several times):
> > All components that are not explicitly flagged as
> > published APIs/libraries can be changed by us at will.
> > External consumers will have to adapt.
> 
> So every SAMBA_LIBRARY without private_library=True and with
> a vnum= is a published API? 

Yes, that is exactly the rule.  There is also a declaration about public
headers, we could have a rule copying those into a spot in the git tree
like we generate ABI files if you want, so you have to explicitly
acknowledge changing those (it is then up to the developer to be
sensible about being forward-compatible there). 

> I don't think we can make
> promises for things like samba-util, tevent-util or even
> samba-hostconfig. 

The public status of these is, as I'm sure you already guessed, for
OpenChange.  I know there is a strong feeling that OpenChange shouldn't
be using our 'internal' APIs, but I would return that we we allow
OpenChange is actually better than what we demand of VFS writers, who
build against our internal headers (vfs.h is not public), and non-public
functions like lp_*() (samba-hostconfig covers the lpcfg_() variant). 

Before we go and make life difficult for OpenChange, I would ask that we
think carefully about if it really is better that we make OpenChange
take a pile of Samba and copy it into their own repo?  That may not even
be practical in this case, but I say that because that is the situation
CTDB was in, and part of the benefit of merging it back into Samba is to
eliminate that copy.  

I'm certainly glad OpenChange didn't take a full fork of Samba like
winexe did at one point, and which wmi-client is still burdened with. 

The situation of OpenChange being close-but-separate may not be ideal,
but it *has* worked out pretty well for quite some time, and is a model
we should consider extending, not retracting, to better support VFS
modules that need very similar things (both being plugins into samba).  

At some point, we will also see the same issues around our python
bindings, written primarily and tested solely for our internal use, and
FreeIPA which makes great use of them. 

Andrew Bartlett

-- 
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba


-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba