splitout of samba-debug (was: Re: [SCM] Samba Shared Repository - branch master updated)
Jelmer Vernooij
jelmer at samba.org
Thu Jan 15 08:53:36 MST 2015
On Thu, Jan 15, 2015 at 10:47:32AM -0500, Simo wrote:
> On Thu, 2015-01-15 at 15:27 +0100, Jelmer Vernooij wrote:
> > On Thu, Jan 15, 2015 at 03:17:59PM +0100, Volker Lendecke wrote:
> > > On Thu, Jan 15, 2015 at 12:54:53PM +0100, Jelmer Vernooij wrote:
> > > > On Thu, Sep 18, 2014 at 11:03:03PM +0200, Volker Lendecke wrote:
> > > > > via 25df58a lib: Make samba-debug a private library
> > > >
> > > > > commit 25df58a853d8d3ecab2705687453193cb676976c
> > > > > Author: Volker Lendecke <vl at samba.org>
> > > > > Date: Thu Sep 18 14:50:50 2014 +0200
> > > > >
> > > > > lib: Make samba-debug a private library
> > > > >
> > > > > Signed-off-by: Volker Lendecke <vl at samba.org>
> > > > > Reviewed-by: Jeremy Allison <jra at samba.org>
> > > > >
> > > >
> > > > This change removes the debug library symbols from our public libraries, making
> > > > them inaccessible to any non-Samba code - including OpenChange. As Julien just
> > > > discovered, this breaks the use of OpenChange with Samba 4.2.
> > > >
> > > > Can we revert this change, at least for 4.2? We can discuss whether
> > > > OpenChange should use the Samba DEBUG() interface or whether it can do its
> > > > own logging, but that would not be an easy change to make this far in the cycle.
> > >
> > > Feel free. I don't like it that we now can't change our
> > > internal library structures anymore, but if we have to do
> > > this, then feel free to revert my changes.
> > I'll coordinate with Julien. The cleanup seems useful and I don't think we
> > should hold back on it in general, it's just that this particular one is problematic
> > for OpenChange.
>
> Openchange can't simply define their own DEBUG() macro ?
> It's not hard ...
If it does, it won't be able to write to the Samba log files. It would also
force OpenChange to use the exact same signature for its DEBUG() macro
as Samba currently has, rather than something that suits it.
> > > How do we make sure we don't mess up things again? This kind
> > > of cleanup will happen again, and we need a strict check for
> > > this in autobuild.
> > There is infrastructure in the build system to prevent API/ABI changes, which
> > we already use for talloc/tevent/tdb/ldb. We should use it for the public Samba
> > libraries too.
>
> Except we haven't done this so far because our non-stable libraries are
> in no condition to stabilize. We need to first decide what are public
> and what are private interfaces, then split headers and filter private
> symbols out of the public libraries (by moving them in private libs).
It would allow us to at least detect when we make changes to the current
public API/ABI. When we are aware of the changes we are making, we
can decide whether those changes are acceptable.
Considering the current set of public APIs to be set in stone seems
unreasonable, but we should at least be careful when making changes
to APIs in use by external projects like OpenChange or FreeIPA.
Cheers,
Jelmer
More information about the samba-technical
mailing list