RPM packages don't list their distribution about duo_client_python

[xdesai]

Hi gcoxmoz,
Since this package is completely python it really shouldn't be platform dependent. So it's a little confusing to me that you're seeing different package contents between distros. Could you clarify what those differences are? Or at least what types of things are different.

[gcoxmoz]

Sure thing. If I build a python package for rhel6 (assuming there's no .so library), it's noarch because it's python, but it'll land files in /usr/lib/python2.6. Building the same package for Cent7 would be noarch, but land in /usr/lib/python2.7.

Unless you specify %dist in the release, you're going to build two packages with the exact same name, except one package is providing files for EL6 and the other for EL7.

rpm -qa|grep ^python on most boxes will show an 'el6' or 'el7' for reasons like this. So, to be clear, noarch is correct-but-incomplete. This will get you building things as (example) duo_client-3.1.0-1.el7.noarch.rpm instead of duo_client-3.1.0-1.noarch.rpm.

[xdesai]

Ah that makes sense! Thanks for the clarity on that.
Are you interested in making a pull request for this change? I attempted to use your change exactly and was getting some build errors because python3 tried to do interpolation on the strings in setup.cfg. I was wondering if you had another method you've seen used before.

[gcoxmoz]

I'll send up a PR in a little bit. Unfortunately, I don't have a box with python3 handy to test with, so if you're already hitting an issue then we might Have A Bad Time, but at least we're on the same page as to what we're trying to accomplish, which is the important bit.

[gcoxmoz]

I've worked around this issue (via packaging with fpm and specifying the arch that way), and I have no advice on a PR otherwise. I'm fine if you choose to WONTFIX, but I will leave the issue open in case you wish to pursue it internally.

[AaronAtDuo]

Fun fact, python 3 interpolation needs it to be double %%, but that breaks python 2.

[AaronAtDuo]

@gcoxmoz On the offhand chance you still care about this 3 years later, would you have any concerns with only supporting use of python 3 for building RPMs?

[gcoxmoz]

Same answer as 2019. I personally still have servers/uses that are py2 (hand me that brown paper bag, willya?). But I've also worked around the packaging issues* external to the repo.

Personally, I'm surprised people are willing to ingest a security product as a pip and not as a checksum'ed package, packaged as the creators recommend. But maybe I'm the oddball here.

I don't have a strong opinion, and I can't make this call. I left this open because it's your call. If you choose to wontfix this request, that's fine. If you choose to abandon py2 (whether by making this RFE be py3, or more comprehensively for the whole repo), that's totally reasonable, IMO.

# notes, for sharing, how we do it here.

# building for py2:
fpm -s python -t rpm --rpm-dist "$(rpmbuild -E '%{?dist}' | sed -e 's#^\.##')" --provides python-duo-client duo_client_python/setup.py
#                                                                                ^^ because pep8 naming
# building for py3:
fpm -s python -t rpm --rpm-dist "$(rpmbuild -E '%{?dist}' | sed -e 's#^\.##')" --python-bin /usr/bin/python3 --python-package-name-prefix python3 --provides python3-duo-client --no-auto-depends --depends python36-six --depends python3-setuptools duo_client_python/setup.py  

[AaronAtDuo]

For an immediate win we've done this in a way that works for Python 3. We'll try to find a Python 2 solution if anyone asks for one :)

[AaronAtDuo]

057ad6c