mj@xxxxxx wrote:
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.Les Mikesell <lesmikesell@xxxxxxxxx> kirjoitti:Moving locations is always traumatic. Personally I like stand-alone packages that aren't going to be installed on every machine you have to live under /opt, but if it is ever going to move, do it soon to minimize the number of people who will be affected by already having it installed in the wrong place.As FDS is the basis of a commercial product, RHDS, let's talk about the commercial aspect for a moment. Things which are changed in FDS will eventually go into RHDS. There are already folks with lots of RHDS servers deployed or being deployed into commercial environments. We are already talking about a large number of installations.One of the reasons why I argue so strongly to use RHDS in commercial environments is that it includes all dependencies in an isolated manner, and doesn't change interfaces often. IMO, those features make it currently the most suitable server for commercial usage.
In general, we need to use one copy of the software, and the software should be forward and backward compatible. We have this assurance with NSPR, NSS, and mozldap (since it's under our control :-), so if we need to update NSS on the system to fix a security problem or introduce some new functionality, we can do so with a very high degree of assurance that we will not break any existing apps that dynamically link with those NSS libs we are replacing.
One way we will be able to mitigate this situation is to allow the use of local, isolated libraries. For example, let's say that we do go the FHS route. All of the library dependencies will be in /usr/lib - nspr, nss, mozldap, icu, bdb, netsnmp, sasl. FDS/RHDS will have a private lib directory in /usr/lib/fedora-ds (or /usr/lib/redhat-ds). We will build the software in such a way that you could put a private copy of e.g. mozldap in /usr/lib/fedora-ds that the server will use without affecting the rest of the software in the system.
Finally, if/when we do change the layout, we will be providing migration tools to make upgrades as seamless as possible.
I think it is an orthogonal issue to RFC2251. A lot of people in the linux community have certain assumptions about where to find software, config, log files, etc. This is the market in which we now find ourselves - FDS being used as a NOS directory for linux - hence a lot more requests for features like out-of-the-box support for POSIX, NIS, automount, samba, etc. And support for FHS, since that is what the other linux NOS directory server (openldap) uses, as well as other related software such as autofs, nis, pam, etc.To the people who are complaining about the filesystem layout, understand that FDS is the basis for a complex and _stable_ commercial product. You don't just start fiddling with it if it ain't broken... Moving to FHS is certainly not going to increase sales or product stability, although it might make a few systems engineers who have never heard of RFC 2251 happy for a day or two.
In the past (i.e. Netscape/iPlanet), most of our customers were very large enterprises which used our DS for portals, mail servers, PKI, etc. and just figured out how to make it work for their NOS apps. These types of customers typically didn't really care where the software was installed as long as it was easy to manage, since none of the other large enterprise software had any consistency about where it was installed.
You are correct - RHDS is the downstream for FDS, and there is no way we would be able to make a drastic change like this to FDS without RHDS picking it up.Or am I wrong to assume that these type of proposed changes would also make it into RHDS?
As far as doing FHS for explicit business reasons - the same could be said about RPM packaging - we added support for RPMs when we already had a good package with installer.
-- mike -- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
