Description of problem: As distributed by the upstream developers, the valgrind package compiles itself to support both 32-bit and 64-bit. The x86-64 package for FC5 is missing many critical files related to 32-bit support, and installs the 64-bit files in a location that does not agree with the choice made by upstream. Please quit needlessly patching and breaking upstream's source. Version-Release number of selected component (if applicable): I think it was 3.1 or 3.x.1 (whatever FC5 uses now) How reproducible: 100% Steps to Reproduce: 1. install all valgrind packages and 32-bit dev tools 2. gcc -m32 helloworld.c 3. valgrind ./a.out Actual results: does not find the x86-linux files, and thus does not run Expected results: runs without complaint Additional info: Everything else seems to work for 32-bit development. I can use gcc, etc., so the stuff is installed.
If you want to trace 32-bit programs, you need to install both valgrind*.i386.rpm and valgrind*.x86_64.rpm.
Why is valgrind special in a bad way? I have no such problems with gcc. There are no such problems with upstream valgrind. I never saw an option to install 32-bit support. Thus, I conclude that the package is broken.
Also, obviously: To the extent that the packages overlap, I want the result to be deterministic. It's not OK to have binaries that might be 32-bit or 64-bit depending on which package I install first. I would expect such packages to conflict. They damn well should. There are already bug reports related to a failure to conflict. (user uninstalls one of the two, leaving binaries supposedly provided by the other RPM but really not, and now the needed libraries have gone missing) In any case... where is it? On the i386 CD-ROMs??? Of course I did not burn those. No i386 RPM is offered to me. I ended up using a web browser and rpm2cpio. I'm definitely not about to mess with installing a wrong-arch RPM that fails to mention that it conflicts with the native RPM.
In what bad way? valgrind handles 32-bit binaries on x86_64 by having a set of 32-bit programs that handle it. Packaging them in *.x86_64.rpm is against all FC packaging guidelines, plus would precluse 64-bit only installs if valgrind is installed. Furthermore, the 32-bit binaries from x86_64 binaries are inferior to those from a pure 32-bit build, due to defficiencies in valgrind configury. The only problem is apparently that valgrind*.i386.rpm is not included in x86_64 composes, so reassigning to distribution, so that both 32-bit and 64-bit valgrind rpms are composed on x86_64. The packages obviously don't conflict, the driver (/usr/bin/valgrind) will be installed for the preferred arch (and even if it is not, the 32-bit one will DTRT too) and the backend binaries are in separate arch path, so they don't overlap.
Assigning to rel-eng.
I'm not exactly sure what rel-eng is supposed to do with this.
From comment #4: ... The only problem is apparently that valgrind*.i386.rpm is not included in x86_64 composes, so reassigning to distribution, so that both 32-bit and 64-bit valgrind rpms are composed on x86_64. ...
Starting from a fairly normal x86-64 DVD install with the development tools selected: a. gcc does both 64-bit and 32-bit (appears to be 1 gcc and 2 libgcc) b. strace does both 64-bit and 32-bit (appears to be 2 packages) c. if I recall right, gdb also manages to handle both d. valgrind only does 64-bit One of these things is not like the others... As far as I can tell, there isn't any way to get 32-bit support from the x86-64 DVD or even from the x86-64 updates on the web. Fixes, from best to worst: a. package the tool as the upstream developers intended (duh) b. make a special i386 rpm with just the extra files c. tell users to install from upstream source d. put the i386 rpm on the x86-64 DVD/web, despite file conflicts If combined packaging as intended by the valgrind developers "is against all FC packaging guidelines", then obviously the packaging guidlines fail to take this case into account. No surprise; valgrind is an odd case. Fix the guidelines to ensure sanity.
Added to multi-lib.