mj at sci.fi wrote: > Richard Megginson <rmeggins at redhat.com> kirjoitti: >> But there are a lot of people for whom this is a problem. For >> example, we ship 3 versions of NSPR, NSS, LDAP C SDK, ICU, etc. that >> are private to RHDS. In >> addition, we ship our own versions of bdb, cyrus sasl, netsnmp, and >> other software that are in most cases identical to what is already >> included or available for the OS. To remedy this situation, we are >> going to switch FDS/RHDS to build and run against those OS libraries, >> and to not include them in the DS package. So we are already >> committed to not including all of the dependencies in an isolated >> manner. This change will affect the linux and solaris ports. I'm not >> sure how it will affect the HP-UX port. HP already takes our software >> and repackages it in the HP-UX depot format. > > > Argh. This is also a strength of the FDS software, not a problem or > weakness. The package always works because it always includes exactly > what it needs. Using OS libraries can cause all sorts of unpredictable > problems. IMO, removing the included dependencies is also a bad idea. > My list of reasons on the plus side for FDS/RHDS vs OL are being > reduced, strangely. One would have thought that the package could only > get better, not worse. > Consider Symas, how they compile and deliver CDS, which is intended to > be a supportable product for commercial customers. They put the entire > chain of dependencies and software into /opt/symas, so CDS doesn't > break everytime somebody installs a new buggy OS level bdb or OL > library on the machine. There's a good reason for that; it is then a > supportable product. Trusting the proper operation of your critically > important software to the random quality and version numbers of system > libraries is not wise. This is why we also give ourselves the ability to fall back to the safe position of having all of the dependencies installed in a private directory. In most cases it won't be an issue because we control the software (NSPR, NSS, mozldap) or the software isn't that critical (netsnmp, icu). The two exceptions are bdb and cyrus sasl. For bdb, it will be absolutely critical to the operation of the server to use the exact supported version, no more, no less. For the near future, this means 4.2.52 + the recommended patch set, which is what is provided with the latest db4-4.2 packages on RHEL/Fedora Core. Something similar applies for cyrus-sasl and kerberos. The RPM will reflect this in its Requires. > BTW, when is the autoconf support coming? The patch was submitted > quite a while ago, IIRC... Slowly. We're slowly working our way up the stack. Next on the hit list is Admin Server. > > BR, > -- > mike > > -- > Fedora-directory-users mailing list > Fedora-directory-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.fedoraproject.org/pipermail/389-users/attachments/20060703/950cfeb4/attachment.bin
