Les Mikesell <lesmikesell(a)gmail.com> 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.
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.
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.
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.
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.
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.
Or am I wrong to assume that these type of proposed changes would also
make it into RHDS?
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.
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.
Fedora-directory-users mailing list