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

[Jelmer Vernooij]

On Mon, Mar 16, 2015 at 12:51:47PM +0100, Volker Lendecke wrote:
> On Mon, Mar 16, 2015 at 01:13:23PM +1300, Andrew Bartlett wrote:
> > 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
> 
> My take on this question would be a bit different: What made it impossible
> for OpenChange to enter a dialogue with us about us properly exporting
> functionality like our RPC subsystem?
There was interaction about this; it happened in the early Samba 4 days, back
when this wasn't a part of a stable product and we were just trying to
get things to work for OpenChange. It should have been cleaned up before we
released 4.0, but that never happened.

What we need is a story for our public APIs, including what sort of promises
we make about backwards compatibility.

> Why did they have to take our
> source tree and just use internal pieces of it? debug.[ch] is neither
> rocket science nor a particularly beautiful piece of code, so why did
> OpenChange have to use it and thus essentially freeze our possibility
> to easily refactor without causing trouble?

DEBUG() is essentially a part of the DCE/RPC API. pidl generates calls to
DEBUG(). All of Samba's code uses DEBUG() to log so if you
want to have all your OpenChange-related logging in one place, you need to
use DEBUG().

> > 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).  
> 
> Here I disagree. I want to retain the liberty to change our internals
> without a committee deciding about the relative merits of new approaches
> and telling me I have to write compatibility layers. If we invite the
> world to just drop a vnum= anywhere into our wscript_build files, we
> will completely freeze our development.
> 
> We should invite people to better modularize our code, not to just use
> every dark corner of our code and take it as a promised API.

Nothing has to be set in stone. OpenChange can cope with these APIs changing or
being made private. A heads up would be useful though.

Cheers,

Jelmer