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

[Alan DeKok]

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.

  Alan DeKok.