On 08/17/2016 06:52 PM, Nick Coghlan wrote:
On 15 August 2016 at 19:42, Igor Gnatenko
<ignatenko(a)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