<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, May 7, 2013 at 4:28 AM, John Dennis <span dir="ltr"><<a href="mailto:jdennis@redhat.com" target="_blank">jdennis@redhat.com</a>></span> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><span style="color:rgb(34,34,34)"> 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".</span><br>


</div>
<br></blockquote><div><br></div><div>You've pretty much covered it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
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).<br>



<br></blockquote><div><br></div><div><br></div><div>IMHO some of it (e.g. changelog, patches for cert config) is/was necessary.</div><div><br></div><div>My use case was that I wanted the build to be as much drop-in as possible, so I can (for example) upgrade to 2.2.1 as soon as possible when it comes out, but switch to Red Hat's official RPM when it's available, without having to change my config. Without some of the patches, I'd need to modify my config file as well.</div>

<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Would we like to maintain the ./redhat subdirectory?<br>
<br>
No, for two reasons.<br>
<br>
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 :-(<br>



<br></blockquote><div><br></div><div>Yeah. Before 2.2.0 was out, I made sure that I can build RPMs for RHEL5 and 6 (because that's what I use), and submit the necessary changes upstream. It seems to be enough (i.e. those two versions made up for most who need to build a Red Hat RPM), because IIRC there hasn't been a mail to the list about "I need to build FR 2.2.0 RPM for X flavor or Red Hat but the included spec file doesn't work".</div>

<div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

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.<div><br></div>
</blockquote><div><br></div><div>Thanks for the effort.</div><div><br></div><div>If no one else does this first, I'd probably submit patches to make FR debs and RPMs build cleanly before 2.2.1 is out (need to dig out my lxc templates first). That way at least people can build packages for released version.</div>
<div><br></div><div>-- </div><div>Fajar</div></div></div></div>