LAST Call for RC1

[Alexander Bokovoy]

On Wed, Sep 12, 2012 at 12:43 AM, Andrew Bartlett <abartlet at samba.org> wrote:
> 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.
OK.
I tried three times yesterday to get past autobuild but it died with
exceeding maximum amount of time spent.
Looks like yesterday was busy day for autobuilds (five autobuilds at
the same time whole day).


-- 
/ Alexander Bokovoy