Description of problem: Installing 389-ds-base brings /usr/sbin/dscreate command which internally imports lib389. However, the lib389 is not installed as a dependency, therefore the dscreate fails with a python stacktrace. Version-Release number of selected component (if applicable): 389-ds-base-1.4.0.8-1.fc28.x86_64 python3-lib389-1.4.0.8-1.fc28.noarch (of course, not installed for the primary bug report, only for the Additional Info section below). How reproducible: Always. Steps to Reproduce: 1. Run a docker container fedora:28. 2. Upgrade the system and install 389-ds-base. 3. Try to run dscreate. Actual results: ~~~ [root@5b4c4ba130b9 /]# dscreate Traceback (most recent call last): File "/usr/sbin/dscreate", line 15, in <module> from lib389 import DirSrv ModuleNotFoundError: No module named 'lib389' ~~~ Installing the python3-lib389 solves the problem. Expected results: dscreate does not throw the exception. Additional info: python3-lib389 provides dscreate at the very same file system path as 389-ds-base does. I'm currently not sure what should be the correct state of the two packages. This is rather for a discussion, I guess.
Fixed with: https://src.fedoraproject.org/rpms/389-ds-base/c/e1179c50d126475e0902a1b7ccd8bb7861d8f8e6?branch=f28 Closing as CURRENTRELEASE.