On Mon, Dec 20, 2021 at 08:48:17AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
IMO, one of the causes is that we've been keeping the descriptions of older workflows.
Yeah, absolutely. I see that some of that was moved to a "201x-era" entirely separate doc — it might be good to be more aggressive with that.
[...]
Using macros for things that *change* is reasonable: we certainly wouldn't want to search&replace the version string when it changes during version upgrades, and we can't hardcode the library path, because it changes between architectures. But for things that *never change* during the lifetime of the package, what is the point of using macros? When you create a package for a different python module, you're going to start afresh. The spec file should be as readable as possible for _that
I think a lot of people actually _do_ want to start with a working example and modify. Actually, my first instinct was to start with the "python-pello" example https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_example_s... rather than from the blank one.
- The machinery to make every package be python-... while generating an actual python3-... subpackage is awkward. Are we stuck with that forever?
Yes, I think we'll have this for the foreseeable future. On EPEL, you can have multiple python versions, so we *need* the subpackages there. Maybe we'll be able to hide the binary package name once we have package generators (https://github.com/rpm-software-management/rpm/issues/329).
That would be amazing.