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 <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/