[Rpm-maint] [rpm-software-management/rpm] Handle Python extras trough reverse requirements encoded in provides (#1061)

[Petr Viktorin]

I won't be able to think through all the edge cases soon to give you "this doesn't work, because..." kind of feedback. But "reverse requirements" do look viable.
I guess my question is: when can this be done, relative to proper support for dynamic subpackages?
* if later, or just a little sooner: Don't bother.
* if a bit sooner: Put it in pyproject macros as an implementation detail, but document that it shouldn't be done manually. As much as possible, ensure it can be easily switched to dynamic subpackages.
* if much sooner (years): Go for it all the way :)

---

@decathorpe
> I am also reluctant to introduce another source of "if" rich dependencies, which still aren't really correctly handled by some tools, not even some dnf commands (e.g. repoclosure)

That sounds like "if" rich dependencies are unfixably unreliable. Should they be deprecated?

@decathorpe
> Can we extend pyp2rpm to generate these "extras" subpackages automatically in the .spec files? rust2rpm does it this way for optional crate features.

pyp2rpm is a nice tool for initial packaging, but not useful for ongoing maintenance. It generates a specfile for you, but to update, you either need to put in upstream changes (good luck noticing changes in extras!), or re-generate the spec (throwing away any changes you made).
To make ongoing maintenance work, anything in pyp2rpm also needs to be doable manually. Instead of "extend pyp2rpm" you want to "change packaging guidelines"; pyp2rpm should follow those (if/when its dev(s) get to it).

@decathorpe
> I basically meant providing something that can require something - like a proper virtual package specifed by Provides that can also specify Requires. So, like a "virtual subpackage" without it being a "real package". Like you simulate it with your option 3.

Sorry, I don't understand. Do you have a better way of doing what "option 3" does, or are you asking if such a better way exists?


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1061#issuecomment-584096928
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20200210/c5bc35a8/attachment.html>