% sudo dnf install python2-zmq Last metadata expiration check performed 0:03:01 ago on Wed Oct 14 10:26:17 2015. Dependencies resolved. =============================================================================================================== Package Arch Version Repository Size =============================================================================================================== Installing: python2-zmq x86_64 14.7.0-2.fc24 koji 501 k replacing python-zmq.x86_64 14.7.0-1.fc23 Transaction Summary =============================================================================================================== Install 1 Package Total size: 501 k Installed size: 1.4 M Is this ok [y/N]: y Downloading Packages: [SKIPPED] python2-zmq-14.7.0-2.fc24.x86_64.rpm: Already downloaded Running transaction check Transaction check succeeded. Running transaction test Error: Transaction check error: file /usr/lib64/python2.7/site-packages/pyzmq-14.7.0-py2.7.egg-info from install of python2-zmq-14.7.0-2.fc24.x86_64 conflicts with file from package python-zmq-14.7.0-1.fc23.x86_64 Error Summary ------------- Perhaps with the name change it needs an Obsoletes for the old name?
Hmm, according to [1] there is an Obsoletes python-zmq < 14.7.0-2.fc24, which should obsolete your version, that you have installed. Or am I misreading a number here? [1] http://koji.fedoraproject.org/koji/rpminfo?rpmID=6903540
Well, rpm doesn't seem to like it, so it's not a dnf issue: % sudo rpm -Uvh python2-zmq-14.7.0-2.fc24.x86_64.rpm Preparing... ################################# [100%] file /usr/lib64/python2.7/site-packages/pyzmq-14.7.0-py2.7.egg-info from install of python2-zmq-14.7.0-2.fc24.x86_64 conflicts with file from package python-zmq-14.7.0-1.fc23.x86_64 The guidelines suggest that obsoletes shouldn't use macros, perhaps the .f24 is confusing it there somehow?
Looking at rpmdiff output I can see this: $ rpmdiff python-zmq-14.7.0-1.fc23.x86_64.rpm python2-zmq-14.7.0-2.fc24.x86_64.rpm S.5..... NAME removed PROVIDES python-zmq(x86-64) = 14.7.0-1.fc23 added PROVIDES python-zmq = 14.7.0-2.fc24 added PROVIDES python2-zmq(x86-64) = 14.7.0-2.fc24 added OBSOLETES python-zmq < 14.7.0-2.fc24 [...] It looks like Provides: python-zmq%{_isa} = %{version}-%{release} is missing.
Thanks Dominik. This should now be fixed in python-zmq-14.7.0-3.fc24.
It doesn't seem so: <nilsph> Error: Transaction check error: <nilsph> file /usr/lib64/python2.7/site-packages/pyzmq-14.7.0-py2.7.egg-info from install of python2-zmq-14.7.0-3.fc24.x86_64 conflicts with file from package python-zmq-14.7.0-1.fc23.x86_64
It seems this conflict arises because setuptools does not place the .egg-info into a directory and uses a file now. Can setuptools be adjusted/patched to always create the .egg-info directory otherwise we hit a RPM limitation [1]? The .egg-info format says: ``.egg-info`` format: a file or directory placed *adjacent* to the project's code and resources, that directly contains the project's metadata. How can be ensured that it _always_ creates a directory? [1] https://fedoraproject.org/wiki/Packaging:Directory_Replacement
This seems like something we should ping upstream about. I don't know the reason for the change and if we just change things here we could break something else. Would you be willing to file an upstream issue? or would you like me to?
I am not sure this is a python-setuptools issue. Other packages aren't behaving this way. Rebuilding the f23 python-zmq package on f24 does give a directory: https://koji.fedoraproject.org/koji/taskinfo?taskID=11585874 So, I think it's some other change in the python-zmq spec from 14.7.0-1 to 14.7.0-3, but I can't see what off hand. :(
ok. I take that back. I think it is. ;) I am not sure how it's deciding when it should unzip or not, but I think we can make it always do so. https://koji.fedoraproject.org/koji/taskinfo?taskID=11586867 is a python-setuptools with a patch that adds: [easy_install] zip_ok = 0 to setup.cfg Unfortunately I am running low on time to test it today. If someone else could do so and let me know if it fixes things that would be great. Otherwise I will try tomorrow.
*** Bug 1276770 has been marked as a duplicate of this bug. ***
Hmm, I thought it is checking `zip_safe` in bdist_egg, but it doesn't seem to work still here locally with the patch just checked in in git... :/ Even if we find a way to always unzip it, wouldn't we get then the same problems for other packages that had an .egg zip and then would have that unziped?
Actually using setuptools (python-zmq was using distutils before), solves this issue and there is an unpacked python egg: https://koji.fedoraproject.org/koji/taskinfo?taskID=11865352
huh. ok. then should we just move on? Or do you think this might be something other packages hit?
If distutils is doing the installation it will create a .egg-info file, if setuptools is doing it, it will create an .egg-info directory. If you want it to always use a directory, then you should ensure setuptools gets imported in every setup.py.
So it seems we should somehow make sure, that always setuptools OR distutils is used and that it stays consistent with the package. We were just discussing using pip to install the package, which always yields an egg-info or dist-info directory. So I guess, we can close this and move on and have a look at pip to install the package.