On 10/25/2011 07:47 AM, Phil Mayers wrote:
On 25/10/11 12:37, Victor Guk wrote:
Hi, I want to install freeradius on RHEL5. I downloaded tar.bz2.(version 2.1.12) Run *rpmbuild -ba freeradius.spec*, but get an error:
There are "freeradius2" RPMs in the RHEL channels.
I suggest you either:
a. Install one of those, or b. Download the .src.rpm for one of those, and re-use the .spec file
The problem seems to be that the .spec file is out of date and not naming all files, as is required.
I don't use the bundled .spec file, so haven't looked at it in years. We should probably just use the one that RedHat are using these days.
Yes, the bundled spec file gets out of sync. The RHEL 5.8 update will have freeradius2-2.1.12 in it but it won't be released until the next quarterly update which is currently scheduled for GA in Februrary. In RHEL 5 the package is named freeradius2 because RHEL 5 originally shipped with freeradius 1.x and once a package ships in RHEL that doesn't maintain it's configuration we can't rebase it, it has to stay so as not to affect users of the original package. For RHEL 5 you can't just take the Fedora SRPM and build it, RHEL 5 being older has some differences. (Hint: add the missing files to the existing RHEL 5 freeradius2 spec file, there is a minor packaging bug related to pam you'll miss and you will have to adjust the patch for the certificate configuration (or just remove it) and that will get you something nearly identical to what will show up in the 5.8 update. My first inclination was to just attach the necessary files and let you build it yourself but then I recalled how we're prohibited from sending customers RPM's out of band from the normal distribution channel. There is nothing dark and sinister about this, rather it's a practical response to a serious problem. Customers who received out of band RPM's from engineering were calling for support on those RPM's. But the support team can't provide support for packages they've never seen, have not been through our QE process, nor does support have any access to the package, they can't install the package or run it. So how can they support it? I'm sure you understand the issue. I'm fairly certain the rule against providing pre-built RPM's outside the distribution channel also applies to providing the SRPM, but I'll check. FWIW when we provided freeradius2 RHEL 5 packages a while back on my personal web page I had to apply for a waiver to do that. The reason the waiver was granted was because we knew there was going to be a significant delay before the freeradius2 packages appeared in the RHEL 5 channel. But in this instance the updated 2.1.12 freeradius2 packages are currently in QE testing and are being staged for the quarterly update. Yes, things move slower in enterprise distributions, that's why they are more stable. And yes we do a lot of testing for RHEL. -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/