On Tue, Apr 14, 2020 at 9:27 AM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote: > > On 14. 04. 20 17:40, Troy Dawson wrote: > > On Tue, Apr 14, 2020 at 8:30 AM Miro Hrončok <mhroncok@xxxxxxxxxx> 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#comment-30941 > >> > >> 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 _______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
