3.0.0 needs no patches. I merged the cert config patch.

That's why that one's commented out (it's never called). :-)

No, I was actually incorrect here, apologies. The purpose of bootstrap is to provide a method of certificate creation for systems which don't have make. It's still included.

Ok, so bootstrap can stay then (for those who prefer keeping their dev and production boxes separate)... Unless there is a distinct preference for using make. Stefan -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom

On 07/02/2013 10:59 AM, stefan.paetow@diamond.ac.uk wrote:

...

I'm surprised we still need the other patches, I thought I had sent all those upstream, seems to me a new release should not need patches from an old release.

I commented three out, but I wasn't sure about the exclude-config-file one, so I left that in. I'll happily remove that if it's not necessary :-)

Currently you've got: Patch0: freeradius-exclude-config-file.patch Patch1: freeradius-dhcp_sqlippool.patch I don't think you need the freeradius-exclude-config-file.patch because Alan D. fixed that issue. That patch is actually from the FR git repo. I'm surprised it applied, it should either already be in 3.0 or 3.0 implements the same thing differently. FWIW the patch is to exclude certain well known files from being read as config files. Did 3.0 move to reading only config files with a specific extension? 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.

...

I don't think the new build system is using libtool so anything related to libtool is now cruft (that includes removing .la files, etc.)

Righty-ho then. I'll strip that away.

...

The URL for the Red Hat FAQ in the FreeRADIUS Wiki has changed, the one in the README (generated in the spec file) is now invalid and needs to be updated (something I should have fixed but missed).

Okie, will do that then.

...

I apologize but I don't have time at the moment to work on packaging 3.0 because other tasks trump it at the moment, that however may change depending on some upcoming management decisions.

No worries... just wanted to make sure it gets done properly first time around.

Stefan

On 2 Jul 2013, at 16:49, <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?

It has no dependencies. It's a dummy driver used by rlm_sql which does absolutely nothing. It's purpose, other than use in config examples, is to allow use of the rlm_sql query log functionality without connecting to an actual database. It must be included in any packages which install rlm_sql. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team

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

That shouldn't be needed any more, either. The dhcp_sqlippool module should be installed in mods-available/. This means it won't be loaded by default.

The patch is necessary because v2.x loads the module by default, IIRC.

Excellent. I'll pull that out then. Stefan -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom