Centos Yum Packages

[John Dennis]

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 at redhat.com>

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/