packaging: migrate to declarative setup.cfg and remove system-installed data_files

[mcepl]

This refactors the packaging to follow modern setuptools/PEP 517 practices:

• Move package metadata (name, version, author, description, license, classifiers) into setup.cfg for declarative builds.
• Use version = attr: servicereportpkg.get_version to retrieve version dynamically.
• Add console_scripts entry point for servicereport CLI instead of installing a standalone wrapper script.
• Drop data_files entries for manpages, docs, and systemd unit — these should be installed by distro packaging, not via pip/wheels, to ensure correct FHS placement.
• Remove obsolete RPM compression workaround.
• Simplify setup.py to a single setup() call.

This improves PyPI compatibility, wheel portability, and distro packaging integration.

[hramrach]

This should also update the sample spec file provided in the git repository.

[mcepl]

This should also update the sample spec file provided in the git repository.

Actually, if it was according to me, I would remove that SPEC file from the upstream repository completely. After spending many many years around Linux distro packaging, I am firmly persuaded that SPEC files (or the debian/ thingy) should include ONLY distribution specific stuff. Everything else should be in the platform neutral configuration files (exactly like setup.cfg and/or pyproject.toml). And of course, if it should be distribution specific it should not be in the upstream repository. Particularly for the Python packages, openSUSE and Fedora macros differ in quite many important ways and generally it is better not to mix them. Also, packagers should be free to fix and change SPEC files freely and modifying those through pull requests (or even worse, Gerrit submissions! oh, horror!) to reviewers who actually don’t care that much about distro packaging is awkward and slow.

[hramrach]

Providing an example is useful, especially since python install system is no longer usable for fully installing the tool, and missing bits need to be supplemented by the spec file.

[mcepl]

Feel free to modify them (you have openSUSE ones, after all), I said, what I would do.

[hramrach]

I don't follow python packaging so I will trust you when you say that current up-to-date python packaging practices do not account for data files.

Unfortunately, distribution packaging does need installation of data files.

You could say that the party that does not care about distribution packaging in the first place is python upstream maintaining those python packaging schemes.

Also you could say that before your change the spec file was redundant, and not particularly useful.

However, after your change the python packaging no longer installs the data files.

Then some other place should track the data files to install. Given that there already is a spec file it is the natural place to track the files to install that python refuses to. Even if it is unlikely to be usable as is the list of files not tracked by python can be there.