Releases, locking and ldb

[Stefan Metzmacher]

Am 27.06.2017 um 04:36 schrieb Andrew Bartlett via samba-technical:
> On Tue, 2017-06-27 at 08:07 +1200, Andrew Bartlett via samba-technical
> wrote:
>> On Mon, 2017-06-26 at 18:11 +0200, Stefan Metzmacher wrote:
>>>
>>> Would sssd break with these changes?
>>>
>>> Do we have other known external users, beside openchange?
>>
>> I'm not sure.  I'll check with apt reverse depends when I get to the
>> office. 
> 
> For Debian:
> 
> libldb1
>   Reverse Depends: ldb-tools (>= 2:1.1.27-1+b1)
>   Reverse Depends: libldb-dev (= 2:1.1.27-1+b1)
>   Reverse Depends: python-ldb (= 2:1.1.27-1+b1)
>   Reverse Depends: python-samba (>= 2:4.5.8+dfsg-2)
>   Reverse Depends: python-sss (>= 1.15.0-3)
>   Reverse Depends: python3-sss (>= 1.15.0-3)
>   Reverse Depends: samba (>= 2:4.5.8+dfsg-2)
>   Reverse Depends: samba-dsdb-modules (>> 2:4.5.8+dfsg-2)
>   Reverse Depends: samba-libs (>= 2:4.5.8+dfsg-2)
>   Reverse Depends: samba-testsuite (>= 2:4.5.8+dfsg-2)
>   Reverse Depends: sssd-ad-common (>= 1.15.0-3)
>   Reverse Depends: sssd-common (>= 1.15.0-3)
>   Reverse Depends: sssd-dbus (>= 1.15.0-3)
>   Reverse Depends: sssd-proxy (>= 1.15.0-3)
>   Reverse Depends: sssd-tools (>= 1.15.0-3)
> 
> That limits the fallout pretty well it seems.

The good thing is that due to LDB_MODULE_CHECK_VERSION()
Samba and sssd are only runtime compatible with the version
they're build against.

Would "ldb:tdb: Ensure we correctly decrement ltdb->read_lock_count"
affect any old caller in any bad way?

And what about "tdb: Remove locking from tdb_traverse_read()"?

Whould something like this on the samba_dsdb module
in 4.6 work around the problems (and keep it only as broken as it
already is):
- always call ldb_handle_use_global_event_context()
- overwrite read_lock/read_unlock() to be a no-op

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20170627/8e233e8f/signature.sig>