On Thu, Aug 29, 2013 at 02:49:17PM +0000, stefan.pae...@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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
