LAST Call for RC1

[Andrew Bartlett]

On Tue, 2012-09-11 at 15:19 +0300, Alexander Bokovoy wrote:
> On Tue, Sep 11, 2012 at 2:58 PM, Andrew Bartlett <abartlet at samba.org> wrote:
> > 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?
> That's the plan. I cannot finish it before RC1 so next version,
> libpdb.so.1, will be reduced one, with only API needed for pdb
> operations and modules support code. Anything else will be split into
> private libraries. We already discussed with Guenther that ldapsam
> helpers can go into a separate library and get modules linked against
> that one instead. At this rate, it will be 4.1 or so.

OK.  If you have something better before the release, I think it's fair
to patch it up as a bug given the niche situation and use case
involved. 

Andrew Bartlett

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