This is a packaging error.

If you install dscreate like this:

dnf install /usr/sbin/dscreate

The python3-lib389-1.4.2.4-8.module_el8.2.0+366+71e3276f.noarch package is pulled in, but no libraries on which it depends.

Manually installing 389-ds-base works around the problem.

To fix this, properly add the dependency from python3-lib389 to 389-ds-base-libs.

@mreynolds Shouldn't dscreate be part of 389-ds-base not lib389?

The dependency tree of 389-ds seems to be in some disarray.

When the package is pulled in, a long list of perl dependencies are brought in, when it looks like the perl code has been removed. Then a huge number of python dependencies are brought in.

This is the first time I've seen anyone have a problem with using dscreate after install the module. Are you following the installation guide:

https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/installation_guide/assembly_installing-the-directory-server-packages_installation-guide

This "should" pull in all the required packages, including python-lib389.

The perl dependencies are part of the legacy tools subpackage. We are trying to remove that subpackage in next major release after RHEL/Centos 8 (389-ds-base-1.4.4.x). If you don't use the perl tools then you can remove 389-ds-base-legacy-tools and most of those perl dependencies will go away (a few remain for logconv.pl which is still a part of the core server).

The python dependencies are needed for python-lib389.

@firstyear - awhile ago there was a discussion about where dscreate should live. I think it should stay in python-lib389 along with all the other python CLI tools. Properly installing the module should be sufficient to pull all this in, but I guess we could add a Requires to the 389-ds-base-libs package?

As indicated in the comment above, the tool dscreate was installed like this:

dnf install /usr/sbin/dscreate

Because the package dependencies are not set up correctly, this causes the tool to be installed without the libraries.

This is for the purposes of automation. None of this server (will be) is being installed by hand.

Okay, I misunderstood what was being attempted. Right now lib389 and 389-ds-base are meant to be used together on the same system, and not used separately. So this is an RFE to allow python-lib389 tools to work on system without 389-ds-base package...

As indicated in the comment above, the tool dscreate was installed like this:

dnf install /usr/sbin/dscreate

This is really odd and I don't know why you are doing this. It is installed with python-lib389, so are you are not installing python-lib389?

To fill you in on RPM specifically.

RPM package names are a mess. Noone can make up their mind on what the names should be, or how they should be broken up. Different distros have totally different structures. Different versions of different distros (like the RHEL8 upgrade happening here) have different structures. What package contains dscreate? Go to Google to find 100 wrong answers to this question.

Fortunately RPM rescues us by allowing us to specify a package by the name of binaries in that package. For example: dnf install /usr/sbin/dscreate

Instead of wasting time trying to figure out what package contains that binary, RPM tells us. This is great so far.

RPM also contains some great tooling to make sure that any binary automatically has the dependencies of that binary automatically calculated so that when you install the binary, all of the required dependencies come in too. Again, no dependency hell.

For python code however, this does not work. RPM happily installs the package containing /usr/bin/dscreate, but RPM does not install this package's dependencies. For this reason, the bug was raised - to get this fixed.

This is really odd and I don't know why you are doing this. It is installed with
python-lib389, so are you are not installing python-lib389

I don't know what package I'm installing and I don't care. RPM's job is to do this for me so I don't have to.

On 28 Aug 2020, at 01:50, Mark Reynolds pagure@pagure.io wrote:
=20
=20
mreynolds added a new comment to an issue you are following:
``

As indicated in the comment above, the tool dscreate was installed =
like this:
=20
dnf install /usr/sbin/dscreate
=20
This is really odd and I don't know why you are doing this. It is =
installed with python-lib389, so are you are not installing =
python-lib389? =20

It's legit Mark. You'd also hit this if you do "dnf provides =
"*/dscreate". I used this trick all the time when I was an admin to find =
software I needed. (Who ever remembers what package ss or ip come =
from!).

Anyway, I think that the issue is here is python-lib389 is fine, but =
dscreate should be part of 389-ds-base. python-lib389 can exist on it's =
own, but dscreate needs both 389-ds-base AND lib389, so having it in =
389-ds-base makes sense from the dnf provides behaviour, and for =
creating the right chain of dependencies.=20

Looking at the suse package, we seem to be affected by the same issue :(=20=

So I'll probably submit a fix to that for SUSE in the future.=20

=E2=80=94
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/4302

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.