Bug 1271776 - python2-zmq-14.7.0-2.fc24.x86_64.rpm cannot update python-zmq-14.7.0-1.fc23.x86_64
python2-zmq-14.7.0-2.fc24.x86_64.rpm cannot update python-zmq-14.7.0-1.fc23.x...
Product: Fedora
Classification: Fedora
Component: python-zmq (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Thomas Spura
Fedora Extras Quality Assurance
: 1276770 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2015-10-14 12:32 EDT by Kevin Fenzi
Modified: 2015-11-17 08:46 EST (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-11-17 08:46:49 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Kevin Fenzi 2015-10-14 12:32:17 EDT
% 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
 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?
Comment 1 Thomas Spura 2015-10-14 15:27:16 EDT
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
Comment 2 Kevin Fenzi 2015-10-14 17:44:06 EDT
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?
Comment 3 Dominik 'Rathann' Mierzejewski 2015-10-15 13:35:56 EDT
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.
Comment 4 Thomas Spura 2015-10-16 03:56:21 EDT
Thanks Dominik.

This should now be fixed in python-zmq-14.7.0-3.fc24.
Comment 5 Thomas Spura 2015-10-16 04:43:55 EDT
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
Comment 6 Thomas Spura 2015-10-16 05:53:00 EDT
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

How can be ensured that it _always_ creates a directory?

[1] https://fedoraproject.org/wiki/Packaging:Directory_Replacement
Comment 7 Kevin Fenzi 2015-10-16 14:07:23 EDT
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?
Comment 8 Kevin Fenzi 2015-10-26 14:28:07 EDT
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: 

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. :(
Comment 9 Kevin Fenzi 2015-10-26 15:34:28 EDT
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. 

is a python-setuptools with a patch that adds: 

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.
Comment 10 Thomas Spura 2015-10-30 18:12:30 EDT
*** Bug 1276770 has been marked as a duplicate of this bug. ***
Comment 11 Thomas Spura 2015-11-15 10:51:46 EST
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?
Comment 12 Thomas Spura 2015-11-16 07:28:24 EST
Actually using setuptools (python-zmq was using distutils before), solves this issue and there is an unpacked python egg:
Comment 13 Kevin Fenzi 2015-11-16 15:18:16 EST
huh. ok. then should we just move on? Or do you think this might be something other packages hit?
Comment 14 Donald Stufft 2015-11-17 08:27:33 EST
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.
Comment 15 Thomas Spura 2015-11-17 08:46:49 EST
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.

Note You need to log in before you can comment on or make changes to this bug.