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 <jden...@redhat.com>

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Reply via email to