Richard Megginson <rmeggins(a)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
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.
Fedora-directory-users mailing list