<div dir="ltr">On Tue, Jul 2, 2013 at 10:49 PM,  <span dir="ltr"><<a href="mailto:stefan.paetow@diamond.ac.uk" target="_blank">stefan.paetow@diamond.ac.uk</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">> The freeradius-dhcp_sqlippool.patch is probably still needed because<br>

> the file being referenced only exists in an optional sub-package, which<br>
> if isn't installed will (or used to) cause an error.<br>
<br>
</div>Ok, I've left that one in. I also realised that SQLite is supported, so I've made that an optional package (like krb5, mysql, etc). Does rlm_sql_null.so relate to any of the SQL modules specifically or is it a general module?<br>

<br>
The SPEC as updated a few minutes ago built ok.<br>
<br></blockquote><div> </div><div>Can you put it on github, so it'd be easier to review and see the changes?</div><div><br></div><div>My suggestion about packaging, is that in the packaging recipes included upstream, there should be some level of consistency in patches, configure flags, and how modules are handled. We currently have:</div>
<div><br></div><div>- debian: enable-strict-dependencies, with-experimental-modules=no, disable-developer, one radiusd->freeradius rename patch, include everything not explicitly listed by another module in main package.<br>
</div><div>- suse: no strict-dependencies, with-experimental-modules, disable-developer, no patches, include all modules in main package.</div><div>- redhat (current v2.x.x branch): no strict-dependencies, no experimental-modules, no disable-developer, one patch (freeradius-cert-config.patch), include all modules in main package, but keep existing separate packages (e.g. freeradius-mysql), with no file in it, for ease-of-upgrade purposes.</div>
<div><br></div><div>I suggest to have these things consistent in all packages:</div><div>(1) no patches, except for the debian rename patch</div><div>(2) no strict-dependencies</div><div>(3) with-experimental-modules</div>
<div>(4) disable-developer</div><div>(5) include all modules, or all modules not explicitly separated in different package, in the main package<br></div><div><br></div><div>This way:</div><div>- the package is generic enough for those who simply want to build a binary package that works for their distro</div>
<div><div>- the package is optimized enough for production use, without extra debugging code</div></div><div>- most changes to the code, including new module addition, will not require editing the package recipe, thus reducing the work required</div>
<div>- a "minimal" build, with only the minimum build-required packages installed, will have a stable set of recommended module, plus whatever experimental module that can be built using the installed requirement</div>
<div>- a "complete" build, with all modules (including experimental ones), can be built by having extra dependencies installed before the build process, without the need to adjust the recipe</div><div>- experimental modules will be built when the dependencies are available, but will not be enabled by default (due to modules-available/enabled directory structure).</div>
<div>- in both cases, the number of packages wlll remain the same, but the main package will have different number of modules, depending on which dependencies are available during build time</div><div><br></div><div>-- <br>
</div><div>Fajar</div></div></div></div>