unversioned public libraries in Samba (was: Re: ntdb in Samba?)
jelmer at samba.org
Sun Mar 15 18:29:50 MDT 2015
On Mon, Mar 16, 2015 at 01:13:23PM +1300, Andrew Bartlett wrote:
> 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:
> > 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.
Actually, OpenChange started out as a fork of Samba. The main reason I
got involved with it was to get it to just ship its own sources that
merely linked against Samba. As part of this, I made Samba install a
bunch of its headers (this was still the pre-alpha SAMBA_4_0 CVS
branch) so that OpenChange could link against Samba libraries.
So I'm at least partially responsible for this mess.
I'm not sure when we started installing this many headers though;
perhaps that happened when we transitioned to waf?
> 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).
FWIW, I'm currently working on getting OpenChange to have its own
configuration system and logging. I'll update this thread when
all of that happens. OpenChange should no longer depend on Samba
in the future, except for (optional) DCE/RPC support.
Jelmer Vernooij <jelmer at samba.org> - https://jelmer.uk/
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: Digital signature
More information about the samba-technical