Bug 1091815
| Summary: | python3.i686 and python3.x86_64 don't coexist. | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Maciej Żenczykowski <zenczykowski> |
| Component: | python3 | Assignee: | Miro Hrončok <mhroncok> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 20 | CC: | amcnabb, bkabrda, mhroncok, mstuchli, tomspur |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | python3-3.3.2-15.fc20 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-06-10 03:05:20 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Maciej Żenczykowski
2014-04-28 06:31:12 UTC
You're right, both python3-libs and python3-devel shouldn't depend on python3.%{arch} to correctly support multilib. We need to fix this, thanks for the report!
btw. pkgconfig seems to solve this in some other way. (as far as I can recall no force override installs were done on this machine) # rpm -q pkgconfig pkgconfig-0.28-3.fc20.x86_64 pkgconfig-0.28-3.fc20.i686 # file -sL /usr/bin/pkg-config /usr/bin/pkg-config: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=19c51fc26c1a0b9deccf3bbdf41e79f6bae79d52, stripped # rpm -V pkgconfig.i686 S.5...... /usr/bin/pkg-config <- because it's the x86_64 binary # rpm -V pkgconfig.x86_64 Perhaps that's a pkgconfig packaging bug? (it's annoying verification of pkgconfig.i686 fails) Or maybe that's a different way to resolve this bug? The pkgconfig behaviour is described at [1] as: """ When a conflict is found between two packages corresponding with different arches, the installed file is the one from the preferred arch. This is very common for executables in /usr/bin, for example. """ I'm wondering, that that didn't work for the python3 package... [1] http://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks So I did this: http://pkgs.fedoraproject.org/cgit/python3.git/commit/?h=python3.4&id=c75d3be7c820e642618d317a468e3773de91c8ab However python3-devel conflicts with itself on different arch because the content of /usr/bin/python3.4m-config differes: --- i686/usr/bin/python3.4m-config 2014-05-26 21:14:42.107827014 +0200 +++ x86_64/usr/bin/python3.4m-config 2014-05-26 21:14:54.530866589 +0200 @@ -33,8 +33,8 @@ exec_prefix_build="/usr" exec_prefix=$(echo "$exec_prefix_build" | sed "s#$exec_prefix_build#$prefix_real#") includedir=$(echo "/usr/include" | sed "s#$prefix_build#$prefix_real#") -libdir=$(echo "/usr/lib" | sed "s#$prefix_build#$prefix_real#") -CFLAGS=$(echo "-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -D_GNU_SOURCE -fPIC -fwrapv " | sed "s#$prefix_build#$prefix_real#") +libdir=$(echo "/usr/lib64" | sed "s#$prefix_build#$prefix_real#") (snip) A solution to this might be to modify the script to be the same on each arch, for example by adding some if/else statements similar to [1]. Or to rename the script to something arch specific and add a wrapper similar to the one in [1]. I.e. do (something like) this at the end of %install section: mv %{buildroot}%{_bindir}/python%{LDVERSION_optimized}-{,`uname -m`-}config echo -e '#!/bin/sh\nexec `dirname $0`/python%{LDVERSION_optimized}-`uname -m`-config' > \ %{buildroot}%{_bindir}/python%{LDVERSION_optimized}-config However I'm not sure if this wouldn't break something else. [1] http://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks#Multiarch.2C_binaries_and_compilation_scripts So now in rawhide python3-devel can coexist with itself from a different architecture. Maciej, should I issue an update for Fedora 20? It can't hurt can it? It shouldn't. When I was rebuilding Python 3.3 in Fedora 20 with this fix, a test failed. http://koji.fedoraproject.org/koji/taskinfo?taskID=6906280 I'm sure it was not introduced by my fix as it doesn't affect the tests at all. Will consult this with other Python maintainers later today or tomorrow. (In reply to Miro Hrončok from comment #8) > When I was rebuilding Python 3.3 in Fedora 20 with this fix, a test failed. > > http://koji.fedoraproject.org/koji/taskinfo?taskID=6906280 > > I'm sure it was not introduced by my fix as it doesn't affect the tests at > all. Will consult this with other Python maintainers later today or tomorrow. That's prolly related to [0], it was fixed in rawhide but looks like the fix did get to f20, I'll take care of it. [0] http://bugs.python.org/issue20901 Thanks. python3-3.3.2-13.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/python3-3.3.2-13.fc20 Package python3-3.3.2-13.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing python3-3.3.2-13.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-6853/python3-3.3.2-13.fc20 then log in and leave karma (feedback). python3-3.3.2-15.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/python3-3.3.2-15.fc20 python3-3.3.2-15.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report. |