+++ This bug was initially created as a clone of Bug #147553 +++ As discussed with David, the intention in the Rawhide kernel-devel packages is to make it possible to install multiple of those for different archs in parallel. As shown below, it does not work for all of them. David reported that he was able to install the ppc and ppc64 devel packages in parallel, maybe that's because of ppc64 being multiarch and "allowing" ppc packages too. # rpm -q kernel-devel package kernel-devel is not installed # rpm -Uvh kernel-devel-2.6.10-1.1126_FC4.i586.rpm kernel-devel-2.6.10-1.1126_FC4.i686.rpm warning: package kernel-devel = 2.6.10-1.1126_FC4 was already added, replacing with kernel-devel <= 2.6.10-1.1126_FC4 Preparing... ########################################### [100%] 1:kernel-devel ########################################### [100%] # ls /usr/src/kernels/ 2.6.10-1.1126_FC4-i686 # rpm -Uvh kernel-devel-2.6.10-1.1126_FC4.i586.rpm Preparing... ########################################### [100%] package kernel-devel-2.6.10-1.1126_FC4 is already installed # rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}' kernel-devel kernel-devel-2.6.10-1.1126_FC4.i686 -- Additional comment from ville.skytta on 2005-02-09 02:45 EST -- Oh, and "rpm -U" vs "rpm -i" does not affect the problem in any way. -- Additional comment from riel on 2005-03-14 22:35 EST -- Mmmm, not sure how to fix this bug in a backwards compatible way... -- Additional comment from riel on 2005-03-15 10:54 EST -- One aspect of this bug are file conflicts in /lib/modules/${KVERREL}/, in particular the symlinks build and source. Those can be fixed by moving the symlinks into the kernel-* packages, out of kernel-*-devel, as suggested in bug #149210. I have proposed a patch for that today. -- Additional comment from riel on 2005-03-29 14:53 EST -- And indeed, RPM isn't willing to install the two - even though there are no longer any file conflicts. Over to fedora-maintainers to figure out what we want to do... # rpm -ivh i586/kernel-devel-2.6.11-1.1208_FC4.i586.rpm i686/kernel-devel-2.6.11-1.1208_FC4.i686.rpm warning: package kernel-devel = 2.6.11-1.1208_FC4 was already added, skipping kernel-devel < 2.6.11-1.1208_FC4 error: error reading from file i586/kernel-devel-2.6.11-1.1208_FC4.i586.rpm -- Additional comment from riel on 2005-05-19 16:22 EST -- I guess the code we have now is as far as we should go ;) -- Additional comment from ville.skytta on 2005-10-27 15:02 EST -- Cc'ing Jeremy per today's FESCO meeting. Re: comment 5, no objections here.
I think we need to make it so we can have multiple of these installed just to make building easier... it's not required for the Extras case, since each arch will be built as a separate run and thus buildroot.
Use --badarch.
Or for x86 we don't have transaction color set if we do cat /etc/rpm/macros %_transaction_color 1 rpm -iv kernel-devel-2.6.14-1.1765_FC5.i586.rpm kernel-devel-2.6.14-1.1765_FC5.i686.rpm Preparing packages for installation... kernel-devel-2.6.14-1.1765_FC5 kernel-devel-2.6.14-1.1765_FC5 kernel-devel-2.6.14-1.1765_FC5.i686 kernel-devel-2.6.14-1.1765_FC5.i586
Changing transaction_color for kernel-devel packages is almost certainly going to lead to other surprises in transactions that contain kernel-devel packages. <shrug>
NEEDINFO_ENG has been deprecated in favor of NEEDINFO or ASSIGNED. Changing status to ASSIGNED for ENG review.
This bug is still around for a really long time without anyone touching it -- do we really still want to fix it? It's even marked as FC6Blocker, but I see no real reason thy this should be a blocker for FC6.
It affects manual rpm(8) use on RawHide/FC6 .ppc64 (as it uses .ppc/.ppc64 duality): $ wget http://sunsite.mff.cuni.cz/pub/fedora/development/ppc/os/Fedora/RPMS/gmp-4.1.4-7.ppc.rpm http://sunsite.mff.cuni.cz/pub/fedora/development/ppc/os/Fedora/RPMS/gmp-4.1.4-7.ppc64.rpm $ rpm -i --test gmp-4.1.4-7.ppc.rpm gmp-4.1.4-7.ppc64.rpm error: error reading from file gmp-4.1.4-7.ppc64.rpm It is a regression as it does not occur for RHEL4U4: rpm-4.3.3-18_nonptl.ppc but is affects RawHide: rpm-4.4.2-32.ppc It affects also upstream rpm-4.4.2. It affects only .ppc vs. .ppc64 but for example IMO not .x86_64 vs. .i386. Architecture of the rpm program does not need to be .ppc or .ppc64.
Installing identical NEVR packages simultaneously (even if different arches) is blocked in rpmtsAddInstallElement.That policy prevents errors from users and developers blasting away with globs. Install in different transactions if absolutely necessary. Its really unclear (to me) what advantage there is in installing multiple, identical NEVR, packages simultaneously.
Just that if some script needs to install both architectures - why it should split it into two commands? It is even complicated for a shell script to automatically resolve dependencies and split the installation dependencies-wise into two steps. Moreover "error reading from file" is definitely inappropriate message for such case. There really were some bugreport(s) regarding misleading glob usage?
How hard is it to run rpm -Uvh twice? Not very hard at all imho. The previous error message is less misleading: warning: package gmp = 4.1.4-7 was already added, skipping gmp < 4.1.4-7 I'm not sure what you mean by "bugreport(s) regarding misleading glob usage". Users have been doing rpm -Uvh *.rpm for years with various stupid and silly problems reported against rpm because of wrong "stuff" picked up by the glob.
(In reply to comment #12) > How hard is it to run rpm -Uvh twice? Not very hard at all imho. But it doesn't work here without a rpm -e in between. With rpm-4.4.2-15.2 in FC5, I can't get rpm to install same-NEVR'd i586 and i686 kernel-devel packages on a i386 box in parallel, not even in different transactions. --force "allows" doing it, but after doing so rpm -q (expectedly) reports only one kernel-devel (the latter, forced one) installed and rpm -e will erase only files of the latter. This version of rpm does not understand the --badarch option suggested in comment 2.
There are several issues here, separate bug reports, not "me too" pileups, please.
I'm not sure exactly what different issues are here, just pointing out that the suggested solutions (--badarch, several transactions) to the original problem which is still in the bug summary (in case they were suggested solutions to _that_ one) do not appear to work for me.
The issues are (at least) 1) gmp != kernel-devel, the package format is quite different (since the kernel debutantes insist on AutoReqProv: no, there are no colored files, and the code paths are very different than for gmp). 2) its's not a "regression" in rpm-4.4.2, but rather a bug fix. The implementation to force only a single package of same NEVR and color in a transaction is known broken in rpm-4.3.x, simultaneous identically named installs happen to work because of, say, CLI alphabetic ordering, not otherwise. Note that the implementation in rpmlib pays attention to package color which the kernel debutantes have chosen to turn off with AutoReqProv: no, hence causing changes in rpm install behavior. 3) Erasures have an additional NEVR uniqification that is entirely different than installs
4) The error msg reported by rpm, and the warning message that reports a package has been replaced/skipped rather than added is not displayed unless --verbose is added.
User pnasrat's account has been closed
Reassigning to owner after bugzilla made a mess, sorry about the noise...
Based on the date this bug was created, it appears to have been reported against rawhide during the development of a Fedora release that is no longer maintained. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained. If this bug remains in NEEDINFO thirty (30) days from now, we will automatically close it. If you can reproduce this bug in a maintained Fedora version (7, 8, or rawhide), please change this bug to the respective version and change the status to ASSIGNED. (If you're unable to change the bug's version or status, add a comment to the bug and someone will change it for you.) Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.
This bug has been in NEEDINFO for more than 30 days since feedback was first requested. As a result we are closing it. If you can reproduce this bug in the future against a maintained Fedora version please feel free to reopen it against that version. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp