>>>>> "JH" == James Hogarth <james.hoga...@gmail.com> writes:
JH> Do just to be clear from your wording you are talking about RHEL
JH> python packages that are known as python-foo in RHEL rather than
JH> python2-foo there, since there is no other python within base to
JH> cause confusion?
Right, there are 166 such packages. And the issue isn't the name of
those packages; it's whether you can expect to have some dependency on
python2-foo satisfied on both Fedora and EPEL7. Fedora would like to
start moving towards that in the near future.
JH> Of course by guidelines python- on Fedora should be pointed at
JH> python3- these days as that's the default runtime - correct?
python3 is not the default runtime in any release of Fedora. (It's
still python2 and will remain as such for the forseeable future.) The
default runtime is defined as the target of the /usr/bin/python
symlink. That's different from what we say about which version of
Python a package should be using if it supports both. (That's python3.)
The packaging guidelines don't indicate what packages should Require:.
They don't really say what they should BuildRequires:, either, besides
python2-devel or python3-devel. We are trying to move towards
increasing stricture here, but first we wanted to mandate that
everything actually Provides: python2-* first. Since we can't depend on
RHEL ever doing that, any stricture we do introduce in the future will
cause additional headache for EPEL packages.
I'm just trying to head that off before it starts getting bad.
JH> So these proposed would be not actually conflicting with base (no
JH> python2- in base) but just sort of supplementing them to make
JH> packaging EPEL python stuff easier on dependencies with less %if
JH> {?el6} conditionals?
Exactly. I obviously don't want to introduce any conflicts, and they're
against the EPEL guidelines in any case.
JH> How should this be maintained going forward into 7.3+ in case RH
JH> bring more into base...
They would be removed. If we set the version of the dummy package to
zero, they won't even get in the way if a RHEL package does start
providing python2-whatever, since the RHEL version would then always
take precedence.
JH> Unless you want to handle checking each milestone for fresh
JH> python packages to dummy?
Yes, that was the scripting I mentioned. It's not particularly
difficult to see which python-* packages currently provide python2-* and
to compare those against the list of dummy packages we're providing.
It's not tough to check regularly and this should be done even if any
possible conflicts are harmless.
JH> In principle I think it a worthwhile endeavour in practice I think
JH> it might complicate bug reporting to the correct component (EPEL vs
JH> RHEL and any future python packages missing it).
Not sure how this is any different from anything with a similar name to
something in EPEL. If there are any misreported issues, it's a pretty
quick click to change the component. I don't really expect that this
would cause much in the way of problems, though, since these packages
would never show up in the deplist of any RHEL package, and they contain
no files so any automatic bug reporting setup wouldn't involve them.
- J<
_______________________________________________
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
