Build RPM

[John Dennis]

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

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