On Thu, Aug 29, 2013 at 02:49:17PM +0000, stefan.paetow@diamond.ac.uk wrote:
Agreed on the support contract thing. If something is apparently "unsupported" when it's broken, just run the "supported" version on a test system, reproduce the problem, and go from there. If you know the problem is to do with the newer features, forget the paid support and ask here like you just did.
If the support is worth anything, of course, then I'm sure they'll be delighted to build later packages for you that include the patch. :-)
I'm discussing this within Red Hat already. They are not that upgrade-shy (if it doesn't change the API/ABI), but it takes longer to get approvals from all people involved.
RedHat does follow this list, so perhaps it is worth contacting them to point out that this patch would really be appreciated, even if it ends up in an EPEL package (which should still be acceptable).
freeradius belongs to the core group of technologies in Red Hat, so it's unlikely to allow a replacing package in EPEL (unless it is called freeradius3 or freeradius221 or similar).
That said, I commiserate with the original poster that yes, when the policy is that you're only allowed to use vendor packages, you're limited in what you can and cannot do.
Thanks! -- Axel.Thimm at ATrpms.net