On 09/22/2011 11:58 AM, Aaron Oas wrote: > 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@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. I've rebuilt 389-dsgw with adminutil 1.1.14 - this is 389-dsgw-1.1.7-2 - it is now available from the Testing repos, and should be available from the Stable repos very soon. 389-dsgw-1.1.7-2 should work with 389-adminutil-1.1.14-1 - please give it a try.
Sorry about this - seems that upgrading to a newer version of autoconf/automake/libtool had the unfortunate side effect of changing the .so filename version. > > - Aaron > > > > > -- > 389 users mailing list > [email protected] > https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/389-users
