Bug 171970 - Cannot install kernel-devel packages for all archs in parallel
Cannot install kernel-devel packages for all archs in parallel
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Panu Matilainen
bzcl34nup
: Regression
Depends On:
Blocks: FC7Target
  Show dependency treegraph
 
Reported: 2005-10-28 10:53 EDT by Jeremy Katz
Modified: 2008-05-06 20:17 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 20:17:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jeremy Katz 2005-10-28 10:53:46 EDT
+++ 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@iki.fi 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@redhat.com on 2005-03-14 22:35 EST --
Mmmm, not sure how to fix this bug in a backwards compatible way...

-- Additional comment from riel@redhat.com 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@redhat.com 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@redhat.com 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@iki.fi on 2005-10-27 15:02 EST --
Cc'ing Jeremy per today's FESCO meeting.  Re: comment 5, no objections here.
Comment 1 Jeremy Katz 2005-10-28 11:13:12 EDT
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.
Comment 2 Jeff Johnson 2005-10-31 10:53:55 EST
Use --badarch.
Comment 3 Paul Nasrat 2005-12-15 14:40:31 EST
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
Comment 4 Jeff Johnson 2006-01-20 15:14:13 EST
Changing transaction_color for kernel-devel packages is almost certainly going to lead to other surprises 
in transactions that contain kernel-devel packages. <shrug>
Comment 6 David Lawrence 2006-04-18 16:31:06 EDT
NEEDINFO_ENG has been deprecated in favor of NEEDINFO or ASSIGNED. Changing
status to ASSIGNED for ENG review.
Comment 7 Thorsten Leemhuis 2006-08-16 14:38:12 EDT
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.
Comment 8 Jan Kratochvil 2006-09-16 17:06:03 EDT
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.
Comment 10 Jeff Johnson 2006-10-03 17:54:59 EDT
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.
Comment 11 Jan Kratochvil 2006-10-03 20:33:12 EDT
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?
Comment 12 Jeff Johnson 2006-10-04 08:28:16 EDT
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.
Comment 13 Ville Skyttä 2006-10-04 13:58:24 EDT
(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.
Comment 14 Jeff Johnson 2006-10-04 14:00:59 EDT
There are several issues here, separate bug reports, not "me too" pileups, please.
Comment 15 Ville Skyttä 2006-10-04 14:13:59 EDT
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.
Comment 16 Jeff Johnson 2006-10-04 14:27:58 EDT
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
Comment 17 Jeff Johnson 2006-10-04 14:33:22 EDT
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.
Comment 18 Red Hat Bugzilla 2007-08-21 01:20:56 EDT
User pnasrat@redhat.com's account has been closed
Comment 19 Panu Matilainen 2007-08-22 02:34:12 EDT
Reassigning to owner after bugzilla made a mess, sorry about the noise...
Comment 20 Bug Zapper 2008-04-03 12:35:43 EDT
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.
Comment 21 Bug Zapper 2008-05-06 20:17:27 EDT
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

Note You need to log in before you can comment on or make changes to this bug.