Description of problem: I wanted to install a number of packages at once, including C/C++ development tools. I also wanted to install some 32bit libraries including glibc-devel.i686 and libstdc++-devel.i686. So these packages were also included in the single 'dnf install' command. Now, surprisingly I see that glibc-devel.i686 is installed while glibc-devel.x86_64 is not. Yum installs glibc-devel.x86_64 as dependency of C development tools, but DNF resolves those dependencies with glibc-devel.i686 which I gave it. Even when I tell it to install libstdc++-devel, it refuses to do so since its .i686 version is installed: =================================== [root@hedayat fedora-pkgs]# dnf install libstdc++-devel Package libstdc++-devel-4.9.2-1.fc21.i686 is already installed, skipping. Dependencies resolved. Nothing to do. =================================== I should explicitly tell it to install libstdc++-devel.x86_64 and then it'll do it. Not only this behaviour differs from yum's, but also it is surprising. While I've installed gcc/g++, I can't compile any program normally since x86_64 packages are not installed! Version-Release number of selected component (if applicable): dnf-0.6.3-2.fc21.noarch How reproducible: 100%
Hi Hedayat, when you specify that you want to install package of compatible architecture, it makes sense that DNF installs it. In the past there was a bug [1] which installed both packages as you expected. dnf install libstdc++-devel -> installs libstdc++-devel.x86_64 (dnf chooses the best architecture) dnf install libstdc++-devel.i686 -> installs libstdc++-devel.i686 dnf install libstdc++-devel.i686 libstdc++-devel.x86_64 -> installs libstdc++-devel.i686 and libstdc++-devel.x86_64 dnf install libstdc++-devel.* -> installs libstdc++-devel.i686 and libstdc++-devel.x86_64 [1] https://bugzilla.redhat.com/show_bug.cgi?id=1054909#c10
Nope, I guess that you misunderstood me. Notice what happens on a x86_64 system: =============== [root@hedayat fedora-pkgs]# dnf install libstdc++-devel Package libstdc++-devel-4.9.2-1.fc21.i686 is already installed, skipping. Dependencies resolved. Nothing to do. =============== Shouldn't it install 'the best' architecture when no arch is specified? Notice that I didn't tell it which architecture I want.
It's correct, you didn't specified arch. This will be documented soon in more detail.
OK, I won't reopen the bug. But, this was an example. In my real world situation, libstdc++-devel was a dependency for gcc-c++, and since libstdc++-devel.i686 was installed already, installing gcc-c++ didn't install libstc++-devel.x86_64, which resulted in a very surprising situation: I installed gcc-c++, but I was unable to compile a hello world C++ program because of linker errors (since GCC will try to compile for the host architecture, which is x86_64 in this case). IIRC, Fedora packaging guidelines suggest that -devel dependencies should be specified without arch. Do you suggest that GCC-C++ should depend on arch specific libstdc++-devel (e.g. libstdc++-devel.x86_64 for gcc-c++.x86_64?) package rather than just libstdc++-devel?
Well, one thing is what does "dnf install libstdc++--devel" mean and a completely different thing is what does "Requires: libstdc++--devel". If it prooves that "Requires: libstdc++--devel" means the current architecture (and not any architecture) it would be a bug in the depsolver no matter of what "dnf install libstdc++-devel" means. But it seems that YUM behaves the same. So, I wonder whether DNF can do anything here. I think it should be rather handled in GCC. Not exactly by "fixing" the "Requires" since it makes sense in some cases.
Hedayat, maybe GCC should require architecture specific library if otherwise it's unusable. When user installs local packages packages from rpm he will run into the same problems. IMO it's not DNF nor rpm bug but a packaging problem.
(In reply to Radek Holy from comment #5) > Well, one thing is what does "dnf install libstdc++--devel" mean and a > completely different thing is what does "Requires: libstdc++--devel". If it > prooves that "Requires: libstdc++--devel" means the current architecture > (and not any architecture) it would be a bug in the depsolver no matter of > what "dnf install libstdc++-devel" means. But it seems that YUM behaves the > same. So, I wonder whether DNF can do anything here. I think it should be > rather handled in GCC. Not exactly by "fixing" the "Requires" since it makes > sense in some cases. Are you sure that yum behaves the same? I was sure that it does not, but I should recheck. As the bug title says, the actual report is about the "Requires: libstdc++-devel" case. (In reply to Jan Silhan from comment #6) > Hedayat, maybe GCC should require architecture specific library if otherwise > it's unusable. When user installs local packages packages from rpm he will > run into the same problems. IMO it's not DNF nor rpm bug but a packaging > problem. It's not completely unusable, since you can compile 32bit programs using "-m32" command line parameter. But it's not a typical use case.
(In reply to Hedayat Vatankhah from comment #7) > Are you sure that yum behaves the same? I was sure that it does not, but I > should recheck. Yes, I'm, if it's not a bug in the latest YUM :) "sudo dnf install libstdc++-devel.i686" and then "sudo yum install gcc-c++" installs just "gcc-c++.x86_64" while "libstdc++-devel.x86_64" is not installed. > It's not completely unusable, since you can compile 32bit programs using > "-m32" command line parameter. But it's not a typical use case. Yes, that's it. Maybe weak dependencies can solve this. Or maybe there is even simpler solution.