Need help with making RPM from v2.x.x branch

[Alan DeKok]

John Dennis wrote:
> Why does FreeRADIUS maintain build configurations for Red Hat and
> Debian?

  Part historical reasons.  RPMs were "difficult" to find, and it was
easier to include RPM scripts in the server.

  It also means it's easy for people to build custom RPMs.  They can use
an established spec distributed with the server.  They don't have to
search for spec files.

> 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.

  Yes.  The files distributed with the server should create *a* package.
 Not *the* canonical package.  It will work, and will follow your system
packaging method.  But it won't be identical to an "upstream" package.

> 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).

  For our purposes, there doesn't need to be.

> 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).

  That's pretty much the goal, yes.

> 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).

  I have a redhat VM around somewhere...

  Alan DeKok.