On 4/22/2014 11:14 AM, Alan DeKok wrote:
Bill Schoolfield wrote:
The ability for a software vendor to use an out of the box (OS supplied package) FreeRadius server is a big deal. It means we don't have to distribute FreeRadius and maintain a bunch of stuff.
That's fine.
Why have modules at all (aside from the shared library benefits) if to use custom ones, you have to provide the whole package?
That's not what I said. You need only supply your module. But it MUST match the package used by the vendor.
As for the wisdom of changing a structure's "structure" based on a debug switch... I've never seen this.
<shrug> I've seen it lots.
Finding the error for me at least took an embarrassing long length of time.
If you had built the module using the method I recommend, you would never have seen the problem.
I'm not developing FreeRadius so I tread lightly saying this, but I think the deployment pattern I described should not necessarily be discouraged or prevented.
If you want a module to be compatible with a vendors package, you MUST build it with the same options, tools, etc. as the vendors package. That is the ONLY way you can guarantee it works.
Understood.
I've rarely seen people ship "bare" dynamic libraries for third-party packages. They usually ship a package, which is compatible with the vendors system.
If you really care about compatibility, send us your module. We'll include it in the next release.
Wow, nice gesture. I'd love that but not an option, unless we provide the source to our library and that of course is proprietary.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html