ldb_handler_fold: public or private?

[simo]

On Tue, 2011-03-22 at 11:03 +1100, Andrew Bartlett wrote:
> On Mon, 2011-03-21 at 08:43 -0400, simo wrote:
> 
> > Well breaking the ABI for free gain us nothing.
> > I would put a comment on the function, and try to remember to turn it
> > into a static the next time we make some big ABI change.
> > 
> > Maybe we can define a macro that will do that automatically ...
> > Something like:
> > #if MAJORVER > X
> > static
> > #endif
> > 
> > So that it will be automatically made static the next time we change ver
> > even if we do not remember that, and then we can remove the if/endif
> > block the first time someone notices.
> 
> Simo,
> 
> I really think this is overkill.  The function should, given the
> circumstances described, be static.  If it's not in a header, then
> nobody is using it (if they are, they are broken and deserve to keep
> both pieces). 

It cost us nothing to avoid this for a while, that's why I proposed that
solution.

> Are you also saying that if a function was declared in ldb_private.h,
> that it also can't be removed?

No, you can remove anything you want from private headers, as their
content shouldn't change the ABI.

> Similarly, the ABI generator doesn't know that we reserve the right to
> change ldb_modules.h defined functions in a minor version, because we
> put an exact version check into ldb module loading. 

Which is something we need to change, rebuilding sssd for every minor
change of ldb is a pain in the arse, as it forces sssd and libldb to go
in locksteps for no good reason. We should have a module version we
change only when there is an actual change needed on the modules side.

And when that happen we should change the Y version imho, this way sssd
can be made to depend on 1.0.x and needs to be rebuilt only when we
switch to 1.1.x

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>