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.

[mcepl]

Unfortunately, distribution packaging does need installation of data files.

Yes, and they could use normal Unix tools for installation. Why does it have to be done by Python installation tools?

This is the short essay generated by Gemini on the topic https://paste.sr.ht/~mcepl/300cd6949aafcf2a81bf3c4de15b6d481cc5b66b and there is not much to say above that.

[hramrach]

Why should python installation tools not install data files, unlike autotools, cmake, rubygems, or whatever else?

It's the job of the installation system to install files. Users of the installation system should not be required to hunt for files the installation system refused to install.

Particularly relevant for this PR the list of files to install including the data files was in the python packaging metadata.

This PR removes the list of data files to install from the python packaging metadata but fails to list the files anywhere else. It removes the data files list without any replacement.