updates so that RPMs build on both RHEL7 and Fedora Core 31

[markgalassi]

Some cleanup which allows the building of RPMs on those two platforms. There are still problems with the python RPMs: I have disabled them and not tested them, although this does not disable python in the source distribution. So RPMs are as before but cleaner, and the source distribution should be unaffected.

[drsteve]

Thanks @markgalassi - the default approach to PRs is that we use a rebase strategy. Your PR appears to have a couple of merge commits that make it incompatible with the revision history of drsteve/master and so it can't be accepted.

Can I ask you to resolve the conflicts? See WORKFLOW.md in the repo for the preferred approach. Right now, I think the cleanest thing to do is probably to check out a new feature branch from the last shared commit, then cherry-pick the commits that actually modify code (or generate and apply patches), push that branch and send a new PR.

Then to clean up your repo, check out the master branch again and do a hard reset to the last shared commit. Then you can rebase your master against drsteve/master once the PR is accepted. I'd recommend changing your repo settings to rebase on pull by default:
git config pull.rebase true
should do it.

If you wanted to just fix this PR (rather than start a new one) then I'd make a new feature branch, reset master to the last shared commit, then cherry-pick the commits you need back onto master. Then force push to update the PR. You'll still need to clean up your master branch after the PR is accepted as the commit hashes may not line up.

I just have one question about the actual changes:

• On line 28 of configure.ac you have a comment after defining THE_PKG_RELEASE. Does autotools ignore everything after the first whitespace? Or does the formatting need fixing?