not able to install FR 3.0.16+git in (pure) Debian 9
aland at deployingradius.com
Mon Sep 11 14:01:06 CEST 2017
On Sep 11, 2017, at 3:42 AM, Martin Pauly <pauly at hrz.uni-marburg.de> wrote:
> I'm afraid you got me a bit wrong here.
That was more of a general rant against bad practice, and not against you in particular.
> 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.
The security fixes are all broken out in git, as patches.
> 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?
We only have so much time in a day.
If you're willing to pull all of the security fixes back into 3.0.14, 3.0.13, 3.0.12, etc, that would be nice.
> 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.
Feel free to do so.
> Why would this help? There's quite a number of people out there who run FR with very limited resources,
Like me, and the other developers.
> 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.
That's all nice. But... it involves *me* doing more work because other people don't want to do more work.
Which isn't a very appealing request.
More information about the Freeradius-Users