[389-users] 389-adminutil package dependency issues fresh install

Aaron Oas AOas at redbrickhealth.com
Thu Sep 22 17:58:27 UTC 2011


I recently spent hours resolving a packaging issue when trying to install 389-ds 1.2.9.9, and thought I would share my finding, which is that the recent 389-adminutil-1.1.14 package version seems to have gone backwards in the library versions it provides.

My system is on Centos 5.5, 64bit, using the regular epel repos with mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=epel-5&arch=$basearch.

I have been installing and uninstalling 389-ds over the past few weeks as I develop and prove out a migration of our ldap server, using a script to manage the yum installs/erases and related cleanup so that my results would be consistent.  I started getting dependency problems after 1.2.9.9 came out, like:

Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package 389-ds.noarch 0:1.2.1-1.el5 set to be updated
--> Processing Dependency: 389-ds-console-doc for package: 389-ds
--> Processing Dependency: 389-ds-console for package: 389-ds
--> Processing Dependency: 389-admin-console-doc for package: 389-ds
--> Processing Dependency: 389-admin-console for package: 389-ds
--> Processing Dependency: 389-dsgw for package: 389-ds
--> Processing Dependency: 389-console for package: 389-ds
--> Running transaction check
---> Package 389-admin-console.noarch 0:1.1.8-1.el5 set to be updated
---> Package 389-admin-console-doc.noarch 0:1.1.8-1.el5 set to be updated
---> Package 389-console.noarch 0:1.1.7-1.el5 set to be updated
---> Package 389-ds-console.noarch 0:1.2.6-1.el5 set to be updated
---> Package 389-ds-console-doc.noarch 0:1.2.6-1.el5 set to be updated
---> Package 389-dsgw.x86_64 0:1.1.7-1.el5 set to be updated
--> Processing Dependency: libadmsslutil.so.1()(64bit) for package: 389-dsgw
--> Processing Dependency: libadminutil.so.1()(64bit) for package: 389-dsgw
--> Finished Dependency Resolution
389-dsgw-1.1.7-1.el5.x86_64 from epel has depsolving problems
  --> Missing Dependency: libadmsslutil.so.1()(64bit) is needed by package 389-dsgw-1.1.7-1.el5.x86_64 (epel)
389-dsgw-1.1.7-1.el5.x86_64 from epel has depsolving problems
  --> Missing Dependency: libadminutil.so.1()(64bit) is needed by package 389-dsgw-1.1.7-1.el5.x86_64 (epel)
Error: Missing Dependency: libadminutil.so.1()(64bit) is needed by package 389-dsgw-1.1.7-1.el5.x86_64 (epel)
Error: Missing Dependency: libadmsslutil.so.1()(64bit) is needed by package 389-dsgw-1.1.7-1.el5.x86_64 (epel)
 You could try using --skip-broken to work around the problem
 You could try running: package-cleanup --problems
                        package-cleanup --dupes
                        rpm -Va --nofiles --nodigest
The program package-cleanup is found in the yum-utils package.
[root at ds03 ~]#  rpm -q --provides 389-adminutil
adminutil = 1.1.14-1.el5
libadminutil.so.0()(64bit)
libadmsslutil.so.0()(64bit)
389-adminutil = 1.1.14-1.el5



I started doing a yum clean all in between every install to make sure there were no issues.  I still failed every time, then suddenly 10 minutes later, an install worked.  I successfully reinstalled with my script a few times, then the next time it failed again with the same dependency complaint.

Ultimately, it turned out that I was sometimes getting 389-adminutil-1.1.13-1.el5 and sometimes getting 389-adminutil-1.1.14-1.el5 as I hit different mirrors after each yum clean all.  The version that resolves the dependency requirements is the *lesser* version: 389-adminutil-1.1.13-1.el5.  What is odd to me is that the older 389-adminutil 1.1.13 version supplies an apparently higher version of libadminutil and libadmsslutil:

rpm -q --provides 389-adminutil
adminutil = 1.1.13-1.el5
libadminutil.so.1()(64bit)
libadmsslutil.so.1()(64bit)
389-adminutil = 1.1.13-1.el5


I.e., 389-adminutil-1.1.14 provides libadminutil.so.0, and 389-adminutil-1.1.13 provides libadminutil.so.1

I haven't gone so far as to dig into which mirrors were providing which versions, but I hope this helps someone else in the same boat, and perhaps even helps the repo or mirror retainers if there is something wrong there.


- Aaron







More information about the 389-users mailing list