not able to install FR 3.0.16+git in (pure) Debian 9

[Martin Pauly]

Alan,
>    That's fine... but the result is that*we*  take the hit of supporting their users who refuse to upgrade.
> 
>    There are people who complain about bugs, get told they're already fixed in newer versions, and then complain that they MUST use the upstream distribution.
> 
>    Well, if you won't upgrade and they won't support you, why is it*my*  problem?  Don't complain to me if you stapled your feet to the floor.

I'm afraid you got me a bit wrong here. I have understood that the Debian approach is basically broken from the main
developer's view (didn't really know it this bad before this discussion, though). I am not asking for "distribution pampering"
here. I am asking for a seperation of security-relevant fixes from functional changes in the official releases.
Actually, the 3.0.15 release already comes pretty close to this. From the release notes I read 4 feature improvements,
but 26 bugfixes, at least 15 of which are security-relevant. So if you had funneled the bugfixes into some extra release,
it would not have made much of a difference, right?

So far, so good. But immediately the question arises what to to with older versions. There will always be people asking
for a security-only release for their old version. So even if you adopted this idea, you would have to impose a practical
limit. In the simplest form, you could  do it only for the current version. In practice I would suggest going back to
some point _you_ decide, e.g. 3.0.12 in this example.

Why would this help? There's quite a number of people out there who run FR with very limited resources,
especially when it comes to software and network skills. Like it or not, this is reality. Many IT departments
are understaffed or underfunded or both. On the other hand, most installations use only a very limited subset
of FR's huge functionality. So once you'vo got it to do what you need, you want to change as little as possible
to address a particular security issue. Other functional improvements can easily be postponed, security fixes
cannot in general.

Thanks for listening
Martin


-- 
   Dr. Martin Pauly     Phone:  +49-6421-28-23527
   HRZ Univ. Marburg    Fax:    +49-6421-28-26994
   Hans-Meerwein-Str.   E-Mail: pauly at HRZ.Uni-Marburg.DE
   D-35032 Marburg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5393 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20170911/beee3e39/attachment-0001.bin>