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

Volker Lendecke Volker.Lendecke at SerNet.DE
Mon Mar 16 05:51:47 MDT 2015

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? 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?

Have we in any way been hostile to them? At least I can not remember
any discussion about them being turned down by us. If that has happened,
please send me pointers to this discussion.

> 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.


SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:kontakt at sernet.de

More information about the samba-technical mailing list