Need help with making RPM from v2.x.x branch
John Dennis
jdennis at redhat.com
Mon May 6 23:28:39 CEST 2013
On 05/06/2013 04:09 PM, Alan DeKok wrote:
> Divyesh Raithatha wrote:
>> Hello all, has anyone had success in building an RPM from the v2.x.x
>> branch from http://git.freeradius.org?
>>
> That should work....
>
>> I am following the information from
>> http://wiki.freeradius.org/guide/Red-Hat-FAQ
>>
>> On a CentOS 6.4 x64 system I was able to build an RPM from 2.2.0 source
>> successfully but I want to get all of the recent patches from the v2.x.x
>> branch.
>
> Go to redhat/freeradius.spec, and delete the following line:
>
> Patch2: freeradius-radtest.patch
>
>
> That should cause it to build.
>
> Alan DeKok.
Why does FreeRADIUS maintain build configurations for Red Hat and
Debian? I suppose it makes sense for the person who wants to build an
RPM or Deb package from the latest repo. It does not make sense for
someone who just wants an RPM package. These project maintained build
configurations are best thought of as "bleeding edge developer stuff".
Make some change and you want to test on Fedora or Debian and need
packages, then these build directories are the goto place, Or for those
cases where a distribution has not caught up with upstream yet, then
this can serve a useful purpose as well (as long as they stay generic,
see below), another variant of the "this is only for the latest and
greatest".
I can't speak for Debian, I'm not a Deb package maintainer, but at least
in the Red Hat world there isn't just one Red Hat distribution, there
are many and each can have different build requirements build
configurations.
Another problem is the spec file under ./redhat is forever getting out
of sync (as evidenced by the OP). Patch sets are a superb example of
this (compounded by the problem there is no single rpm spec file for all
Red Hat versions).
My suggestion is for upstream FreeRADIUS to maintain a generic Red Hat
RPM spec file which is vanilla as possible without any patches
whatsoever. In theory current upstream shouldn't need patches. Also any
customization we might do really should come from us, not upstream. If
one is building an RPM from the current FreeRADIUS version using the
FreeRADIUS RPM spec file then one should get a vanilla FreeRADIUS build
whose only customization extends to assuring the same file locations,
package names, etc. are used. You pretty much get this for free. I would
take an existing spec file strip out all the patches, changelog, etc.
and then one only needs to take a look at the options passed to
configure (I'm thinking about options which control which modules are
built).
The generic RPM spec file that upstream maintains should be exercised on
regular basis. Far too often we've seen upstream changes that required
spec file changes but which were never done (e.g. add/removing modules
and/or other files).
Would we like to maintain the ./redhat subdirectory?
No, for two reasons.
1. It's impossible, as pointed out above there is no single spec file,
each spec file is tied to a specific release. We maintain *independent*
spec files for *every* distribution version we support, at the moment
that numbers in the dozens :-(
2. We already maintain them and they are publicly available for anyone
to download. Trying to maintain multiple copies in multiple repositories
and assuring they all stay in sync doesn't seem justified.
--
John Dennis <jdennis at redhat.com>
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
More information about the Freeradius-Users
mailing list