LAST Call for RC1

[Alexander Bokovoy]

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.

One may argue that static linking of passdb modules is bad but solving
it is not easy as static linking means init functions of those modules
are referenced directly. Removing support for static linking of passdb
modules would mean a refactoring and this is what none is able to
accomplish before 4.0.
-- 
/ Alexander Bokovoy