splitout of samba-debug (was: Re: [SCM] Samba Shared Repository - branch master updated)

Simo simo at samba.org
Thu Jan 15 08:47:32 MST 2015


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

> > 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 has some shortcomings (doesn't detect changes in structs IIRC), but it's
> better than nothing and we can address those shortcomings.

Sure, but this come later, first we need to define *what* we want (and
can) make public.

Simo.

-- 
Simo Sorce



More information about the samba-technical mailing list