LAST Call for RC1

[Andrew Bartlett]

On Tue, 2012-09-11 at 10:12 +0300, Alexander Bokovoy wrote:
> On Tue, Sep 11, 2012 at 9:53 AM, Stefan (metze) Metzmacher
> <metze at samba.org> wrote:
> > Am 11.09.2012 08:46, schrieb Alexander Bokovoy:
> >> On Tue, Sep 11, 2012 at 9:12 AM, Andrew Bartlett <abartlet at samba.org> wrote:
> >>> On Tue, 2012-09-11 at 09:09 +0300, Alexander Bokovoy wrote:
> >>>> On Tue, Sep 11, 2012 at 3:40 AM, Andrew Bartlett <abartlet at samba.org> wrote:
> >>>>> Just to confirm with others on the Samba Team, aside from DNS (and my
> >>>>> continuing fight with GPO ACLs) is there anything else that must be in
> >>>>> RC1?
> >>>>>
> >>>>> Please also update WHATSNEW with anything special that you want
> >>>>> mentioned.  I'll be going RC1 on Wednesday (tomorrow) morning my time.
> >>>>> (Clearly most of my TODO list won't be done by then, but the remaining
> >>>>> items should be small enough to do in the RC phase).
> >>>>>
> >>>>> Naturally, once we do RC1 we focus on bugfixes, along with anything we
> >>>>> find at SDC/the Microsoft IO lab.
> >>>> I need to remove get_userattr_list() from libpdb exports.
> >>>
> >>> I'm a little confused by this whole area.  Shouldn't the list be a
> >>> whitelist, not a blacklist?
> >> White list will come later, when I'll normalize function names to have
> >> a single prefix (pdb_ or passdb_). Right now there are too many
> >> functions with absolutely different naming conventions that are in the
> >> same libpdb. Filtering is applied to those that are part of internal
> >> structure of some modules and never used by others.
> >
> > But why are those names used by external users?
> >From internal structure of some modules? They are not, thus filtering applied.
> Among others there are functions you need to call if you are writing
> passdb modules. We happen to have one outside Samba git, IPA passdb
> module, that depends on some external components from FreeIPA project
> that makes no sense to pull into Samba git.
> 
> In order to change visibility of internal functions we need to apply
> ABI checks. That is only possible with libpdb becoming 'public'
> library because we track proper ABI signatures only for public
> libraries. My patch to allow this tracking for private libraries was
> denied, with a logic that it makes no sense to keep library private
> and yet track its ABI.
> 
> But set of exposed internal functions differ from configuration to
> configuration. The modules can be linked against libpdb dynamicall or
> linked statically into libpdb, like it is happening by default. If
> someone doesn't build ldapsam or builds it dynamically, whole set of
> internal functions will not be linked to libpdb. At this point ABI
> check will notice there are functions missing in the library as
> compared to the pdb-0.sigs file and will report an error on
> (unintended) ABI change. Thus we filter these functions to cover both
> static linking and dynamic linking of passdb modules.

All this makes me feel like we are exposing the wrong library.  Can't we
have a library with just the things we need to expose to write a passdb
module, and nothing more?

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org