FreeRadius 3.0.0 SPEC

[Fajar A. Nugraha]

On Tue, Jul 2, 2013 at 10:49 PM, <stefan.paetow at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-devel/attachments/20130703/1d977c1c/attachment-0001.html>