$ rpmbuild --target=i686 -ba rpm.spec Building target platforms: i686 Building for target i686 error: Failed build dependencies: python3-devel(x86-32) >= 3.2 is needed by rpm-4.11.2-2.3.fc20.i686 # yum install python3-devel.i686 ... Transaction check error: file /usr/bin/python3.3m from install of python3-3.3.2-11.fc20.i686 conflicts with file from package python3-3.3.2-11.fc20.x86_64 file /usr/bin/python3.3 from install of python3-3.3.2-11.fc20.i686 conflicts with file from package python3-3.3.2-11.fc20.x86_64 I'm not sure what the fix is here, should python3-devel.i686 not pull in python3.i686 (ie. of the same architecture) and be satisfied by python3.x86_64 (ie. of any architecture)? Should python3-devel depend on /usr/bin/python3.3m instead of python3.rpm? Should python3.x86_64 provide python3(x86-32) ?
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.