On 14. 04. 20 17:40, Troy Dawson wrote:
> On Tue, Apr 14, 2020 at 8:30 AM Miro Hrončok <mhroncok(a)redhat.com> wrote:
>>
>> On 14. 04. 20 15:56, Troy Dawson wrote:
>>> Hi Miro,
>>> I've taken a look, but haven't done any testing.
>>
>> Thanks.
>>
>>> EPEL6 patch - no. Even if it works, I'd say no. We're at the last
7
>>> months before EOL and I don't want the EPEL6 stuff to have changes
>>> like this. I could be outvoted by this, but I believe most of the
>>> other EPEL packagers would feel this way.
>>
>> Makes perfect sense.
>>
>>> EPEL7 patch - This would require some testing. When we tried to turn
>>> on the python automatic-dependency checking, there were things that
>>> broke on EPEL7 so they never got implemented. What, or how they
>>> broke, I don't currently know. I just know that they did, and there
>>> wasn't a big enough demand to debug. As in zero demand. Nobody asked
>>> for it in EPEL7, only EPEL8. So I'm not even sure this would be worth
>>> the testing. Has anyone asked for this?
>>
>> Not yet. But If we want packagers to start using %pycached, I know there are
>> some of them who would blindly merge their master branch to epel7 and they
>> expect it will work. I suggest that we backport %pycached only, the name is
>> unlikely to clash with anything. %python can be separated and not backported.
>> Sounds good?
>>
>
> Yep, sounds good to me.
Amended
https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/14
>>> EPEL8 patch - We've had requests to have EPEL8 be as close to Fedora,
>>> so I'm in favor of this.
>>> I'm pretty sure the %pycached shouldn't be a problem.
>>
>> I agree.
>>
>>> What is %python supposed to resolve to? To me it looks like
>>> /usr/bin/python ... which there isn't any in RHEL8. And, I thought
>>> Fedora got rid of it also, in favor of specifically doing python2 or
>>> python3. Or did that change?
>>
>> So the main idea was that based on some FPC and RPMdevs discussions about
>> underscor-prefixed macros, packagers should not be using those directly,
however
>> our guidelines were full of referecens to %{__python3}. We have come up with a
>> conclusion:
>>
>> Macros with underscores, such as %__python3 are intended to be reset to change
>> bahvior of other macros (e.g. when you set %__python to /usr/bin/pythhon3.4 on
>> EPEL 7, %{python3_version{ will be 3.4), macros without underscores are to be
>> used in specs (e.g. you do `%{python3} -m pytest` rather than `%{__python3} -m
>> pytest`.
>>
>> Details:
>>
https://pagure.io/packaging-committee/issue/907
>>
https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/27#comm...
>>
>> The only problem was the %{python} macro. When you redefine %__python to a sane
>> (explicit) value, you want %{python} to work, because e.g. %{python_version}
>> works. But we didn't want to encourage usage of "unversioned
python" by adding
>> %{python}.
>>
>> So Fedora now has a %{python} macro: If %__python is /usr/bin/python (backwards
>> compatible default), %{python} gives you an error. If %__python is anything
>> else, %{python} gives that to you.
>>
>
> Ahh ... now that you explain it, I was reading it totally backwards.
> I'd still like to test it on a variety of packages, but unless others
> have some type of objection, as long as it passes the tests, I'm good
> with it.
What kind of packages would need the test? This is mostly backwards compatible.
The only packages that could be problematic are packages that use a constructs
like this:
%{!?python:...} or %if %{defined python}
-> previously %python was not defined, now it is and hence the conditional will
have a different result
Or like this:
%global pyver_sitelib %python%{pyver}_sitelib
-> previously %python was not defined, now it is and hence the code produces
invalid result
I suppose such cases could be figured out with a grep. Is there something like
https://pkgs.fedoraproject.org/repo/rpm-specs-latest.tar.xz but for epel branches?
Yep, I'm having a hard time finding anything relevant to test.
I have verified it doesn't conflict with any other rpm macro, but I'm
pretty sure you had already checked that.
So, I'm giving it a thumbs up.
And I'll give it a thumbs up on the pull requests as well.
Troy