On Tue, Jul 2, 2013 at 10:49 PM, <stefan.paetow@diamond.ac.uk> wrote:
> The freeradius-dhcp_sqlippool.patch is probably still needed because
> the file being referenced only exists in an optional sub-package, which
> if isn't installed will (or used to) cause an error.

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?

The SPEC as updated a few minutes ago built ok.

 
Can you put it on github, so it'd be easier to review and see the changes?

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:

- 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.
- suse: no strict-dependencies, with-experimental-modules, disable-developer, no patches, include all modules in main package.
- 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.

I suggest to have these things consistent in all packages:
(1) no patches, except for the debian rename patch
(2) no strict-dependencies
(3) with-experimental-modules
(4) disable-developer
(5) include all modules, or all modules not explicitly separated in different package, in the main package

This way:
- the package is generic enough for those who simply want to build a binary package that works for their distro
- the package is optimized enough for production use, without extra debugging code
- most changes to the code, including new module addition, will not require editing the package recipe, thus reducing the work required
- 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
- 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
- experimental modules will be built when the dependencies are available, but will not be enabled by default (due to modules-available/enabled directory structure).
- 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

-- 
Fajar