On 04/19/2010 10:40 AM, Alan Buxey wrote:
Hi,
for their 5.5 update. They usually follow the Red Hat release by a few
weeks. (Or you might consider installing RHEL :-)
Also you might want to be aware the RHEL 5.5 update contains FreeRADIUS
2.1.7, not 2.1.8 because 2.1.8 was not available when RHEL 5.5 was frozen.
given that 2.1.8 was bug fixes...and 2.1.9 will be likewise...with no
new feature/method changes....then i'd hope that 2.1.8 (or 2.1.9)
will just appear in 5.5 later as a security/bug update that yum etc
get and install later...just like any other package update?
ie should we worry that 2.1.7 was the point release at freeze time?
The general RHEL policy is *not* to rebase packages (i.e. change to
higher upstream releases). This is done for stability reasons. However
some isolated packages are permitted to be rebased, maily desktop
applications such as firefox. Rebasing servers is something which
rightly gives RHEL engineering management heartburn and sleepless nights
wondering how that might break thousands of critical customer installations.
The simple answer is that you shouldn't expect FreeRADIUS to be rebased
in RHEL, however if there are enough customer issues with FreeRADIUS
2.1.7 it can be brought up for consideration.
RHEL 6 which is under development and is currently in beta testing does
have FreeRADIUS 2.1.8. So a possible solution would be to upgrade from
RHEL 5 to RHEL 6. If FreeRADIUS 2.1.9 is released shortly I *may* be
able to get it into RHEL 6, but as I said RHEL is extremely conservative
and modifying versions that have already been through alpha and beta is
deeply frowned upon, I wouldn't count on it.
If you really want to always have available the latest upstream releases
of any package then electing to install an enterprise distribution whose
primary goal is stability is not the right choice (in fact the two are
mutually exclusive). The correct selection of a cutting edge
distribution with the latest upstream release would be Fedora, not RHEL.
Fedora is the proving ground for subsequent *major* RHEL releases.
Another solution is to stabilize FreeRADIUS such that the need for
frequent version upgrades is not necessary. Rather than adding new
features focus on bug elimination. Some projects have a stable branch
and an "future" branch. The pace of version releases for FreeRADIUS is
"brisk". While that has many merits and the FreeRADIUS developers should
be applauded for their prolific contributions it also has some
downsides, mainly it conflicts with the goals of enterprise stability. A
stable branch would be a much better fit for an enterprise distribution
such as RHEL.
Stability vs. features is just one of the classic trade-offs in computer
science, just like memory usage vs. processor cycles. They really are
polar ends in continuous spectrum, RHEL clearly targets one end of that
spectrum and as a consequence you lose out on the other end. While on
the other hand Fedora focuses on the other end. We do both independently
(Fedora and RHEL), but we can't do both in one distribution.
--
John Dennis <jden...@redhat.com>
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
