This is a wrong place to file the bug. What should be reverted is libldb 1.4 in Fedora 28, then Samba to be rebuilt against previous libldb version.

Done, it was submitted for Samba because Samba is the broken package, my mistake

*** Bug 1602014 has been marked as a duplicate of this bug. ***

libldb-1.4.0 was built in koji for f28 47 days ago. (Requesed by Andreas)
But bodhi update was done 19 days ago by Andreas.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-6f661431ac

I assumed he knew which version is fine for samba-4.8.3.
Because libldb-1.4.0-1.fc28.x86_64 is already in update (due to stable karma +3)

There are few possible ways:
* bump epoch in f28 + return back to 1.3.x
* revert some patched in libldb which were introduced in 1.4.0
* make samba-4.8.3 working with libldb-1.4.x

Realistically we can only bump epoch and get back to 1.3.x. 

From samba-technical@ discussion in June ("Backporting LDB patches please?"):

-------------------------
On Tue, 2018-06-19 at 07:43 +0200, Stefan Metzmacher wrote:
> Hi Andrew,
> 
> thanks! Can you remind me if it's possible to use newer ldb versions
> 1.4.x or 1.3.x with 4.7? Timur asked me about that and I wasn't sure
> as we had some problems with that at some point.

It probably doesn't work, particularly for 1.4, as the DSDB module
stack had to again be changed again when the locking got stricter.

It also simply isn't tested.

I don't suggest mixing Samba with LDB versions different to what it was
released with, and we should probably remove the pretence that this was
ever a good idea (ie like CTDB, just release with Samba).

Andrew Bartlett
-------------------------

and another one from the same thread is:

-------------------------
>
> This again sounds like we should have a separate git repository for ldb!

No, we don't want to use older Samba versions against newer LDB
versions.  The reason we bumped the version to 1.3 and 1.4 was to allow
a release stream without the major changes brought by the GUID index
work and the key-value layer.

These are maintained in the v4-7-test and v4-8-test branch
respectively.

However see my other mail, the experience of the past two years has
shown that the Samba/LDB interactions are much, much more complex than
the current release plan ever imagined.

Andrew Bartlett
---------------------------

(In reply to Alexander Bokovoy from comment #5)
> Realistically we can only bump epoch and get back to 1.3.x. 
> 

We can also do a artificial downgrade with
git diff ldb-1.4.0..ldb-1.3.4 -- lib/ldb
(I know it is a hack)

Bumping epoch is quite tricky as well

Another way might be to rebase to 4.9 in f28. 

Because at least looking at rpmdev-vercmp, we would have to carry the epoch forever in fedora and use the %epoch macro together with all the NVR macros, so the packaging would get more complex.

(In reply to Jakub Hrozek from comment #7)
> Another way might be to rebase to 4.9 in f28. 
> 
> Because at least looking at rpmdev-vercmp, we would have to carry the epoch
> forever in fedora and use the %epoch macro together with all the NVR macros,
> so the packaging would get more complex.

Yes, you can never remove epoch after introducing(bumping).

(In reply to Lukas Slebodnik from comment #8)
> (In reply to Jakub Hrozek from comment #7)
> > Another way might be to rebase to 4.9 in f28. 
> > 
> > Because at least looking at rpmdev-vercmp, we would have to carry the epoch
> > forever in fedora and use the %epoch macro together with all the NVR macros,
> > so the packaging would get more complex.
> 
> Yes, you can never remove epoch after introducing(bumping).

One exception: you can remove epoch if you rename the package. Of course, we *really* do not want to do that either.

But yeah, I think you only have three choices:

1) Upgrade Samba to 4.9 in F28. This would require asking FESCo for permission, as it violates the Stable Updates Policy[1]
2) Bump epoch. This makes packaging slightly more complex and must be carried forwards forever.
3) Lie about the version; leave the version number at 1.4.x but apply a patch that reverts its actual contents to 1.3.x.


Epoch is honestly the "correct" approach here. This is what it was designed for: to allow the version number to go backwards. Once the epoch is in place, maintaining it is not too difficult.

If you *do* opt for 3), I'd prefer it if you encoded the "real" version number into the release field at least, so you can conditionalize on that if you had to. In other words, the correct version is 1.3.4, then the package could be libldb-1.4.0-1.fc28.1.3.4.1.rpm. Breaking down the "release" tag:

1: Matches the number you've already released. In a perfect world, we would have this be zero so we could move to "1" when the real 1.4.0 arrives, but so be it.
fc28: We want this to have a clean upgrade path to F29
1.3.4: The *real* version
1: The pseudo-release of this version.

This will maintain the upgrade path to F29 but it's possible to then use:
Requires: libldb >= 1.4.0%{?dist}.%{real_version}
when needed.


[1] https://fedoraproject.org/wiki/Updates_Policy#Stable_Releases

(In reply to Stephen Gallagher from comment #9)
> If you *do* opt for 3), I'd prefer it if you encoded the "real" version
> number into the release field at least, so you can conditionalize on that if
> you had to. In other words, the correct version is 1.3.4, then the package
> could be libldb-1.4.0-1.fc28.1.3.4.1.rpm. Breaking down the "release" tag:
>

That sounds reasonable way how to avoid introducing epoch. libldb is not upgraded very often in older branches. It will not cause any maintenance problems.
 
> 1: Matches the number you've already released. In a perfect world, we would
> have this be zero so we could move to "1" when the real 1.4.0 arrives, but
> so be it.
> fc28: We want this to have a clean upgrade path to F29
> 1.3.4: The *real* version
> 1: The pseudo-release of this version.
> 
> This will maintain the upgrade path to F29 but it's possible to then use:
> Requires: libldb >= 1.4.0%{?dist}.%{real_version}
> when needed.
> 

Upgrades will not be a problem because libldb >= 1.3.2 works
well with any version of sssd without rebuilding and samba-dc has strict
requires on libldb (%requires_eq libldb).
    
There are following auto-generated requires in samba-dc
   Requires: libldb = 1.3.2 in fc27
   Requires: libldb = 1.4.0 in fc28 (libldb-1.4.0-1.fc28.1.3.4 would match)
   Requires: libldb = 1.4.1 in fc29

I would appreciate testing of following koji build
https://koji.fedoraproject.org/koji/taskinfo?taskID=28414665

A workaround is to run Samba as a single process using the "-M single" option.

This can be set using SAMBAOPTIONS in /etc/sysconfig/samba

SAMBAOPTIONS="-M single"

This has been stable for the last couple of days for my small (but using replication) environment.

(In reply to thunt from comment #12)
> A workaround is to run Samba as a single process using the "-M single"
> option.
> 
> This can be set using SAMBAOPTIONS in /etc/sysconfig/samba
> 
> SAMBAOPTIONS="-M single"
> 
> This has been stable for the last couple of days for my small (but using
> replication) environment.

Have you try packages from comment 11?
I would appreciate testing before creating update.

Just tried to test, and it looks like you also need to rebuild the Samba RPM's (samba-dc in particular) as there are modules in /usr/lib64/samba/ldb that are tied to a specific version of ldb.

Confirming that samba should be rebuilt. The error message now is (when provisioning)

ldb: module version mismatch in ../source4/dsdb/samdb/ldb_modules/acl.c : ldb_version=1.3.4 module_version=1.4.0
ldb: failed to initialise module /usr/lib64/samba/ldb/acl.so : Unavailable

samba-4.8.3-2.fc28 libldb-1.4.0-2.fc28.1.3.4 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-892e145f7e

Tested with latest Samba and libldb builds and everything now seems to be working.

Thanks, please add karma to the bodhi update.

libldb-1.4.0-2.fc28.1.3.4, samba-4.8.3-2.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-892e145f7e

libldb-1.4.0-2.fc28.1.3.4, samba-4.8.3-2.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.