Bug 1369486

Well, crap, someone asked for those.  (They haven't been in EL6 before.)  I added them with the caveat that they test them.  They said they were OK, so I pushed them.

I'll fix them up.  Will you promise to test for me?

Yeah, no problem!

So, uh, I'm confusing this with the python macros I added to EPEL5.  There have been python macros in epel-rpm-macros-6 for quite some time.  I will remove those, but.. I'll not touch these.

If the python macros (with a working definition of %python2_version) are removed from epel-rpm-macros-6, it is imperative that this bug gets fixed or builds will start failing due to it as spec files start to rely on the %python2_version defined in this package python-rpm-macros.

If nobody else prefers to do it, I volunteer.

I'm actually working on them now.

But currently I see that even on el6 python3-rpm-macros exist, which makes absolutely no sense as they can't possibly work.  Of course, I would just have a completely separate spec file for the el6 package since it's so different, but I'm not sure that Orion would like that since he likes to keep one spec for everything.  So I'll wait to talk to him first; maybe he wants to have el6 versions of the macros checked in as separate files and ifdefs in the spec.  

Personally I just have different versions of the same files checked in on different branches but....

Anyway, I'll try to catch Orion on IRC.

Roger, I'll leave it up to your capable hands.

Here's my suggestion for the two failing macros:
%python2_version %(%{__python2} -c "import sys; sys.stdout.write(sys.version[:3])")
%python2_version_nodots %(%{__python2} -c "import sys; sys.stdout.write(sys.version[:3:2])")

Tested to work on RHEL-6.

I'm fine with the el6 branch diverging for python-rpm-macros.  There are already significant differences on the different branchs.

I'm not sure it's worth worrying about the python-3-rpm-macros sub-package.  Nothing should require it.  And if anyone were crazy enough to build python34 for EPEL6 they would be there (I just tried that and I think it will build with some tweaks).

OK.  Given that I was adding the nil defines, I figured I needed to put them somewhere.  If python3 does make it to el6, we can always just remove them and maintainers will have less work to do.

Hi, can I ask what's the status on this bug?

I add it to my list every day but never manage to make it down that far.

The hitch is that for some reason the the python macros package spits out a python3 subpackage, which doesn't (currently) have any use.  If I removed the subpackage I'd have to obsolete it and, well, I don't know if it's of any use to anyone.

But I still want to nil out those python 3 stubs.

I think the plan is:

Fix the python macros package with your fixes.

Remove all python macros from epel-rpm-macros _except_ the two python 3 stubs that are there.

Add a dependency on the python2 macros to epel-rpm-macros so that the python macros are (still) always present.

I'm going to promise to get this done today.  If there's an issue with that plan, I can just unpush the update.

Wouldn't it be best to put the Python 3 stubs into the python3-rpm-macros subpackage? In that case you don't have to remove and obsolete it.

Then I you can make epel-rpm-macros depend on all the four python-rpm-macros subpackages (python-rpm-macros, python2-rpm-macros, python3-rpm-macros, python-srpm-macros).

Having two Python 3 stubs in epel-rpm-macros, and the rest of Python macros in python-rpm-macros seems inconsistent and hard to find.

P.S. If you want, I can push the changes to python-rpm-macros myself, and prepare a patch you can push to epel-rpm-macros, so you can do more important/pressing things.

The thing is, I don't know what that python3 package is used for or why it has ever been generated.  I could remove the macros from it completely, I guess.  Is there any point at all in having them there?  If someone does try to do python3 in el6 then I'm sure they can come back.

I believe it was there because the EPEL-6 and EPEL-7 branches were merged, likely by mistake. I think you can safely remove the content of the python3 macro file and put the two stubs there.

Yeah, it just got merged down there.  Personally I don't see the harm of just leaving it there - nothing requires it (I said as much in comment #7). Leave the stubs in epel-rpm-macros because that provides compatibility and always needs to be there.

Yeah, I completely lost the context, sorry.

Now, for a really fun thing, the python macros packages place the macros in /usr/lib/rpm/macros.d.  Which is a directory that isn't provided by any package, and I don't believe is even used by the version of RPM on EL6.  %rpmmacrodir should the correct thing on all releases.

So I've fixed that all up and brought over a fix for the issue with Amazon Linux (https://bugzilla.redhat.com/show_bug.cgi?id=1347019).  Bodhi will spam this bug shortly.

epel-rpm-macros-6-13 python-rpm-macros-3-11.el6 has been submitted as an update to Fedora EPEL 6. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-d59560b5a8

epel-rpm-macros-6-13, python-rpm-macros-3-11.el6 has been pushed to the Fedora EPEL 6 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-d59560b5a8

Just because I felt like it, I created a Docker container to test this:

git clone http://ttorling.fedorapeople.org/git/epel6-testing-container.git/

epel-rpm-macros-6-13, python-rpm-macros-3-11.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.