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
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
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
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
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
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....