Description of problem: I have configured daily update of packages on CI machine with rawhide. There are not any strict requirements/conflicts between curl and pycurl therefore one of daily update made python2-pycurl unfunctional. sh$ python2 -c 'import pycurl' Traceback (most recent call last): File "<string>", line 1, in <module> ImportError: pycurl: libcurl link-time ssl backend (openssl) is different from compile-time ssl backend (nss) It should be fixed in packaging level and we should not rely on runtime failure. sh$ rpm -q --conflicts libcurl sh$ echo $? 0 sh$ rpm -q --requires python2-pycurl /bin/sh libc.so.6()(64bit) libc.so.6(GLIBC_2.14)(64bit) libc.so.6(GLIBC_2.15)(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.3.4)(64bit) libc.so.6(GLIBC_2.4)(64bit) libcurl(x86-64) >= 7.52.1 libcurl.so.4()(64bit) libpthread.so.0()(64bit) libpython2.7.so.1.0()(64bit) libssl3.so()(64bit) python(abi) = 2.7 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PartialHardlinkSets) <= 4.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsXz) <= 5.2-1 rtld(GNU_HASH) Version-Release number of selected component (if applicable): sh$ rpm -q python2-pycurl curl python2-pycurl-7.43.0-7.fc26.x86_64 curl-7.54.0-3.fc27.x86_64 How reproducible: Deterministic Steps to Reproduce: 1. Install python2-pycurl <= 7.43.0-7.fc26.x86_64 2. try to install curl with openssl support (>=7.54.0-3.fc27_ Actual results: It is possible to install python-pycurl built with nss and curl built with openssl Expected results: It is not possible to install python-pycurl and curl which were compiled with different crypto. Additional info: python2-pycurl-7.43.0-8.fc27.x86_64 requires unsufficient version of libcurl sh$ rpm -q --requires python2-pycurl | grep curl libcurl(x86-64) >= 7.54.0 libcurl.so.4()(64bit) sh$ rpm -q python2-pycurl curl python2-pycurl-7.43.0-8.fc27.x86_64 curl-7.54.0-2.fc27.x86_64 sh$ python2 -c 'import pycurl' Traceback (most recent call last): File "<string>", line 1, in <module> ImportError: pycurl: libcurl link-time ssl backend (nss) is different from compile-time ssl backend (openssl)
This should resolve itself shortly when your CI system picks up curl 7.54.0-3.fc27. I don't think it's usual for explicit conflicts for this sort of issue to happen when packages are changed in Rawhide and not even branched yet, and if they were, I'd think the conflict should go in the python-pycurl package anyway, since that's the one with the runtime compatibility check in it.
(In reply to Paul Howarth from comment #1) > This should resolve itself shortly when your CI system picks up curl > 7.54.0-3.fc27. > > I don't think it's usual for explicit conflicts for this sort of issue to > happen when packages are changed in Rawhide and not even branched yet, and > if they were, I'd think the conflict should go in the python-pycurl package > anyway, since that's the one with the runtime compatibility check in it. NO, python-pycurl built with openssl should require minimal version of curl which is build with opensll. In this case curl-7.54.0-3.fc27.x86_64; because as I mentioned in description curl-7.54.0-2.fc27.x86_64 is built with nss. But requires in python-pycurl will not prohibit older python-pycurl and the latest curl from rawide. In another words, packagers should not rely on fact that user will always call "dnf update". User might update just sub-set of packages on system "dnf update curl"
(In reply to Lukas Slebodnik from comment #2) > But requires in python-pycurl will not prohibit older python-pycurl and the > latest curl from rawide. In another words, packagers should not rely on fact > that user will always call "dnf update". User might update just sub-set of > packages on system "dnf update curl" That doesn't appear to be a universally-agreed opinion: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/34WLAFRIARC4QK5QA7RCP3ZRGO5F7OZD/ "It is expected that users of development releases update the whole system, not piecemeal."
(In reply to Paul Howarth from comment #3) > (In reply to Lukas Slebodnik from comment #2) > > But requires in python-pycurl will not prohibit older python-pycurl and the > > latest curl from rawide. In another words, packagers should not rely on fact > > that user will always call "dnf update". User might update just sub-set of > > packages on system "dnf update curl" > > That doesn't appear to be a universally-agreed opinion: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/ > thread/34WLAFRIARC4QK5QA7RCP3ZRGO5F7OZD/ > > "It is expected that users of development releases update the whole system, > not piecemeal." My interpretation is different. There was issue between python-3.6.0 and python-3.6.1. The most important is that 3.6.1 will get to fedora 26 stable(and it is already there). Let assume that somebody would like to install/update python3-pycurl on fedora 25. "dnf update --releasever=26 python3-pycurl". It would not update just a python3-pycurl but it will also pull python-3.6.1 But if i try something similar with curl; it will break it due to missing dependencies/conflicts. sh# cat /etc/os-release NAME=Fedora VERSION="25 (Twenty Five)" ID=fedora VERSION_ID=25 PRETTY_NAME="Fedora 25 (Twenty Five)" ANSI_COLOR="0;34" CPE_NAME="cpe:/o:fedoraproject:fedora:25" HOME_URL="https://fedoraproject.org/" BUG_REPORT_URL="https://bugzilla.redhat.com/" REDHAT_BUGZILLA_PRODUCT="Fedora" REDHAT_BUGZILLA_PRODUCT_VERSION=25 REDHAT_SUPPORT_PRODUCT="Fedora" REDHAT_SUPPORT_PRODUCT_VERSION=25 PRIVACY_POLICY_URL=https://fedoraproject.org/wiki/Legal:PrivacyPolicy sh# dnf install -y -d0 -e0 python3-pycurl fedora-repos-rawhide warning: /var/cache/dnf/fedora-310f9d37d74ceec1/packages/python3-pycurl- 7.43.0-4.fc25.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID fdb19c98: NOKEY sh# python3 -c 'import pycurl' sh# dnf update --enablerepo=rawhide -d0 -e0 -y libcurl sh# python3 -c 'import pycurl' Traceback (most recent call last): File "<string>", line 1, in <module> ImportError: pycurl: libcurl link-time ssl backend (openssl) is different from compile-time ssl backend (nss) "dnf update --enablerepo=rawhide -d0 -e0 -y libcurl" is very simplified version. Somebody can try new package from rawhide on f25/26 which requires new features from curl-7.54.0; and it will break python-pycurl. It is clear enough that python2-pycurl < 7.43.0-8.fc27 does not work with latest libcurl. In another words there is a conflict between these packages. And rpm has an ability to express conflicts between packages. Fedora packaging guidelines says: RPM has very good capabilities of automatically finding dependencies for libraries and eg. Perl modules. In short, don't reinvent the wheel, but just let rpm do its job. But in this case automatically generated requires does not work as expected. First, if the lowest possible requirement is so old that nobody has a version older than that installed on any target distribution release, there's no need to include the version in the dependency at all. In that case we know the available software is new enough. Prerequisite is false therefore minimal requires in python-pycurl is required. But it does not solve that curl-7.54.0-3.fc27 is incompatible with old python-pycurl. curl-7.54.0-3.fc27 does not require python-pycurl therefore require will not solve this issue but conflict will solve. And that is exactly wat is described in guidelines http://fedoraproject.org/wiki/Packaging:Conflicts#Acceptable_Uses_of_Conflicts: As a general rule, Fedora packages must NOT contain any usage of the Conflicts: field. This field is commonly misused, when a Requires: would usually be more appropriate. It confuses depsolvers and end-users for no good reason. However, there are some cases in which using the Conflicts: field is appropriate and acceptable. And in this case It would not confuse depsolver. Opposite is true; it will help depsolver to find a solution. (upgrade python{2,3}-pycurl as well) Tested with on f25 and dnf/yum-deprecated + https://koji.fedoraproject.org/koji/taskinfo?taskID=19347487
I do not understand what the run-time check brings us in the first place. While it might be useful from upstream point of view, it is an unnecessary obstacle for Fedora users. The TLS backend changes once per 10 years approximately. So it could hardly happen that Fedora users install libcurl and pycurl compiled against different TLS backends, at least, if they use official repositories only. Moreover, if it happens (only in rawhide, once per 10 years), it makes the transition too difficult for no real benefit. Any objections against just disabling the run-time check in Fedora pycurl?
(In reply to Kamil Dudka from comment #5) > Any objections against just disabling the run-time check in Fedora pycurl? What are implications of disabling runtime check? Especially in case of mixed pycurl+nss(f25) and curl+openssl(rawhide).
I am not aware of anything bad that could happen unless the software written on top of pycurl uses features specific to a particular crypto backend. However, if it did, a rebuild of pycurl could hardly fix it, it would just satisfy the run-time check.
(In reply to Kamil Dudka from comment #7) > I am not aware of anything bad that could happen unless the software written > on top of pycurl uses features specific to a particular crypto backend. > However, if it did, a rebuild of pycurl could hardly fix it, it would just > satisfy the run-time check. OK, I think the simplest way would be to test :-) pycurl+openssl+disabled runtime-check and curl-7.54.0-1.fc27.x86_64(still built with nss) and using yum-deprecated. Because python2 -c 'import pycurl' is not sufficient functional testing.
Seems to be related to these: https://github.com/pycurl/pycurl/issues/109 https://github.com/pycurl/pycurl/issues/120 Looks like convenience rather than fixing any particular problem. FWIW, an alternative approach to satisfying this requirement from an rpm standpoint could be to provide libcurl-{nss|openssl|gnutls} = %{version}-%{release} in the libcurl package, and then have downstream users that want a specific backend require that.
Yes, but it would make the run-time check strengthen by an install-time check. Both of them are artificial IMO. The supported ABI of libcurl is kept if the TLS backend is switched. Users should be free to recompile libcurl against a different TLS backend while keeping the rest of their system running (though unsupported from Fedora point of view). I propose to disable the run-time check now. If it triggers any real problem in environments with mixed old/new libcurl/pycurl packages, we can revert it and introduce the stricter RPM dependencies later on.
(In reply to Lukas Slebodnik from comment #8) > pycurl+openssl+disabled runtime-check and curl-7.54.0-1.fc27.x86_64(still > built with nss) and using yum-deprecated. Because python2 -c 'import pycurl' > is not sufficient functional testing. It passed my smoke test as expected.
FYI: Disabled runtime-check would need to be done also in older version of fedora; otherwise it would not solve mixing versions from stable version of fedora and rawhide Comment4. BTW if it is downstream only patch then it will be better to use conflicts as it is used in scratch build. https://koji.fedoraproject.org/koji/taskinfo?taskID=19347487 (upstream first approach :-)
(In reply to Lukas Slebodnik from comment #12) > FYI: Disabled runtime-check would need to be done also in older version of > fedora; otherwise it would not solve mixing versions from stable version of > fedora and rawhide Comment4. I am not against disabling the check in all supported versions of Fedora. It will continue to work where it used to work and break less where it used to break. > BTW if it is downstream only patch then it will be better to use conflicts > as it is used in scratch build. It will not because it would limit users of pycurl for no apparent reason. > https://koji.fedoraproject.org/koji/taskinfo?taskID=19347487 (upstream first > approach :-) Upstream first does not apply here because it is neither bug fix nor a feature. It is just customization at packaging level to make our packages more flexible.
OK
fixed by the following commits: https://src.fedoraproject.org/cgit/rpms/python-pycurl.git/commit/?id=a80dc1d7 https://src.fedoraproject.org/cgit/rpms/python-pycurl.git/commit/?id=4a69345d https://src.fedoraproject.org/cgit/rpms/python-pycurl.git/commit/?id=5a085fb8
python-pycurl-7.43.0-5.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-9bcef6fcd9
python-pycurl-7.43.0-8.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-db9267ee09
python-pycurl-7.43.0-5.fc25 has been pushed to the Fedora 25 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-2017-9bcef6fcd9
python-pycurl-7.43.0-8.fc26 has been pushed to the Fedora 26 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-2017-db9267ee09
python-pycurl-7.43.0-5.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.
python-pycurl-7.43.0-8.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.
the problem persists on Fedora 27 with python2-pycurl-7.43.0-9.fc27.x86_64 installed
(In reply to Guilherme Baufaker Rêgo from comment #22) > the problem persists on Fedora 27 with python2-pycurl-7.43.0-9.fc27.x86_64 > installed Unlikely. The code that used to print the error message in question is no longer being compiled in python2-pycurl-7.43.0-9.fc27: https://src.fedoraproject.org/cgit/rpms/python-pycurl.git/commit/?id=a80dc1d7
This error still persists on Fedora 28. But installing pycurl==7.43.0.2 resolved the error.
(In reply to Parthvi Vala from comment #24) > This error still persists on Fedora 28. Only if you use a custom build of pycurl. > But installing pycurl==7.43.0.2 resolved the error. You are referring to an upstream version of pycurl whereas the TLS backend check is disabled at distribution level. You need to check the precise version of the installed RPM package (and make sure you are actually using it).