First off, I really want to say that we should resist the idea that Red Hat product decisions should hold back Fedora's progress. This python-*/python2-*/python3-* mess has been with us for far too long, and I applaud the Python SIG for putting in the effort to try and get this regularized. Python packaging is still terrible, but regularizing this one thing makes it a little bit less terrible.
>>>>> "AW" == Adam Williamson <adamw...@fedoraproject.org> writes: AW> I'm not sure this list is terribly useful, because of the AW> above. There are thousands of packages that do this, because the AW> 'python2-' provide is not available on some older Fedora release, or AW> on EPEL (and the package is maintained for EPEL as well as AW> Fedora). We can fix older releases and we can fix EPEL. We could potentially fix RHEL by means of metapackages that live in EPEL, if we were serious about it. Just add a "python2-foo" package that has nothing but "Requires: python-foo". We've talked about this for ages but until now there was never any driving need, and while I'm sure it would work fine I don't know exactly what would happen if the RHEL package suddenly acquires its own Provides: python2-foo, or in any other weird dependency scenarios that someone might invent. If nobody can see a problem with that and we agree it would help, I will volunteer create and maintain this metapackage thing. AW> Sprinkling "if (some release number condition) then AW> Requires: python2-foo else Requires: python-foo" all over your spec AW> is a giant PITA and I for one am not very interested in doing it. Well, here's the big thing: Read https://pagure.io/packaging-committee/issue/686#comment-443129. In fact, I'll quote it here. The indented text is my question, the unindented text is ishcherb's reply: " First off, do we really intend for the unversioned "python-foo" to give you the python3 version of that package? We do, and that is what %python_provide macro was intended for. When needed, it will be enough to only modify the macro to make Python 3 subpackages provide python- prefixed names. " So, basically, you simply cannot have a spec which depends on python-foo and assumes it's going to get the python2 version. Obviously this hasn't been done yet because it would break the world, but the point behind posting this big list of packages is to fix them all. And even if Fedora waits two years to do this, old EPEL releases will still be around. So if you really want that magical non-ifdef spec compatibility between Fedora and EPEL, then either RHEL is going to have to add the python2- provides soon or EPEL is going to have to introduce the metapackages I mentioned above. And if you want compatibility between Fedora and RHEL without EPEL present, then %if/%endif is your only real option. The only other way I can see around this is to have some ugly macro which hardcodes knowledge of packages which provide python-* but not python2-* and generates your Requires: or BuildRequires: based on that. I could write one, but I don't particularly want to. If people talk it out and it turns out that's the only solution which people can accept, then I will volunteer to write and maintain a macro like this. Finally, Red Hat itself could clear up this mess a bit by officially saying that it intends to add the python2-* provides on some schedule. Then Fedora could coordinate with that, and we'd all live in a land of ponies and rainbows. What a concept. But I know Red Hat never comments on what they're doing in upcoming products and never commits to dates for upcoming products, so.... - J< _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
