On 08/17/2016 06:52 PM, Nick Coghlan wrote:
On 15 August 2016 at 19:42, Igor Gnatenko <ignate...@redhat.com> wrote:
It can't track/change BR/R's as RPM is Turing complete and impossible to parse.
Imagine, we have pythonXdist(foo) extracted from PyPI metadata, but in
Fedora we still need to add some more BR for that, so we add it. When
new release comes (still without added BR in upstream) rebase-helper
will not be helpful. It can change only version of spec.
This is a self-inflicted problem arising from our current tooling
design, though, since "generate-and-edit" isn't the only way to
supplement upstream metadata: we can also design spec file generators
to accept a supplemental config file in addition to the upstream
metadata.
If we're using that alternate model, then rebase-helper can have a
much easier time of things, since it isn't trying to edit a previously
generated spec file, it's just generating a new one based on the new
upstream metadata and the old supplemental metadata, and seeing if the
result still passes CI.
The more I think about it, the more it seems to me that our plan should be:
- Make it possible for pyp2rpm to use extra data to augment/override
what's in the upstream package.
- Make it standard practice in Fedora to use this data and treat the
spec file as an immutable generated artifact.
- Treat metadata errors/omissions as upstream bugs, provided the desired
state can be expressed in setup.py
- For kinds of metadata that setup.py can't express, strive to add them
to future versions of the upstream packaging format.
- For the far future, perhaps start getting rid of spec files: teach
Koji to generate them, and stop storing them in dist-git.
Helper macros stay orthogonal -- pyp2rpm would just need to learn to use
them.
--
Petr Viktorin
_______________________________________________
python-devel mailing list
python-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org
