Bug 487731 - yum update/upgrade fails if kernel-debuginfo is install (F11/Alpha)
yum update/upgrade fails if kernel-debuginfo is install (F11/Alpha)
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
11
All Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
: Reopened
: 495527 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-27 12:38 EST by Andrew Hecox
Modified: 2014-01-21 18:08 EST (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-06-28 07:21:41 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)
yum clean all && yum -y upgrade failure (8.83 KB, text/plain)
2009-03-17 10:09 EDT, Andrew Hecox
no flags Details
kernel.spec patch (964 bytes, patch)
2009-04-16 02:37 EDT, Roland McGrath
no flags Details | Diff

  None (edit)
Description Andrew Hecox 2009-02-27 12:38:15 EST
on F11/rawhide, if I do a yum update with the kernel-debuginfo package installed, the transaction fails with 'ERROR with rpm_check_debug vs depsolve:':

...
(67/68): kernel-debuginfo-common-2.6.29-0.159.rc6.git3.f |  36 MB     03:28     
(68/68): kernel-debuginfo-2.6.29-0.159.rc6.git3.fc11.i58 | 301 MB     30:13     
--------------------------------------------------------------------------------
Total                                           170 kB/s | 478 MB     47:51     
Running rpm_check_debug
ERROR with rpm_check_debug vs depsolve:
kernel-debuginfo-common-i586 is needed by kernel-debuginfo-2.6.29-0.159.rc6.git3.fc11.i586
Complete!
(1, [u'Please report this error in http://yum.baseurl.org/report'])

ahecox@t61 ~ $ 

I can remove the rpms, install again, and it works fine.

ahecox@t61 ~ $ sudo rpm -e kernel-debuginfo-common kernel-debuginfo
ahecox@t61 ~ $ sudo yum -y install kernel-debuginfo 
...
Complete!
ahecox@t61 ~ $
Comment 1 Andrew Hecox 2009-02-27 12:39:38 EST
this has happened since I installed the debuginfo packages a few updates ago. It definitely worked in F10, not sure where it fell off between there and now though.
Comment 2 James Antill 2009-02-27 17:27:54 EST
This should be fixed by the yum-plugin-auto-update-debuginfo package, should get into Fed-10 "soon". Until then just pass --enablerepo=\*debuginfo.
Comment 3 Andrew Hecox 2009-02-28 13:46:55 EST
Thanks James. Fed-10 or rawhide?
Comment 4 Andrew Hecox 2009-03-03 11:32:28 EST
that didn't work so well:

$ sudo yum --enablerepo=\*debuginfo upgrade
Loaded plugins: dellsysidplugin2, refresh-packagekit
updates-debuginfo/metalink                               |  11 kB     00:00     
Could not parse metalink https://mirrors.fedoraproject.org/metalink?repo=updates-released-debug-f10.91&arch=i386 error was 
File //var/cache/yum/updates-debuginfo/metalink.xml.tmp is not XML
Error: File //var/cache/yum/updates-debuginfo/metalink.xml does not exist
$
Comment 5 James Antill 2009-03-03 13:42:10 EST
That looks like a MirrorManager problem:

https://mirrors.fedoraproject.org/metalink?repo=updates-released-debug-f9&arch=i386

...works, but as you say the 10.91 version doesn't.
Comment 6 James Antill 2009-03-03 13:44:21 EST
It's worth pointing out that nothing with f10.91 is in the returned list ... I guess you want to change them to rawhide, at least until something happens server side.
Comment 7 Andrew Hecox 2009-03-03 13:59:05 EST
should I change the component to mirrormanager?
Comment 8 James Antill 2009-03-06 14:16:18 EST
yeh, I guess ... I'd pinged matt to make sure I hadn't missed something obvious. But he can just assign it back if it's bad.
Comment 9 Matt Domsch 2009-03-06 16:56:01 EST
Thanks for the notice.  I added redirects in the MM database, so that the repos looking for 10.9[0123] will get directed to the corresponding rawhide repos.  Change should take effect within 30 minutes or so.
Comment 10 Andrew Hecox 2009-03-06 16:57:47 EST
thanks Matt -- I'll test next push and close once confirmed.
Comment 11 Matt Domsch 2009-03-07 17:30:54 EST
These URLs are working for me now.  I also updated the release SOP to note that we need to be sure such redirects are in place for all releases (it had said they were just needed for "final" releases, which clearly isn't true anymore).
Comment 12 Matt Domsch 2009-03-07 17:31:35 EST
CURRENTRELEASE.  Not really a code change, but needed to run MM's manage-repo-redirects script to add the prerelease redirects.
Comment 13 Andrew Hecox 2009-03-10 14:08:27 EDT
hmmm, yesterday the upgrade worked, today I get:

$ sudo yum -y upgrade
...
(104/106): kernel-debuginfo-common-2.6.29-0.218.rc7.git2 |  36 MB     00:06     
(105/106): kernel-debuginfo-common-2.6.29-0.218.rc7.git2 |  36 MB     00:05     
(106/106): kernel-debuginfo-2.6.29-0.218.rc7.git2.fc11.i | 303 MB     00:46     
--------------------------------------------------------------------------------
Total                                           6.1 MB/s | 520 MB     01:25     
Running rpm_check_debug
ERROR with rpm_check_debug vs depsolve:
kernel-debuginfo-common-i586 is needed by kernel-debuginfo-2.6.29-0.218.rc7.git2.fc11.i586
Complete!
(1, [u'Please report this error in http://yum.baseurl.org/report'])

$
Comment 14 Andrew Hecox 2009-03-12 10:21:23 EDT
and worked this time.

 - am I hopelessly confused?
 - is this random?
 - did a new fix go in? 

thanks.

Andrew
Comment 15 seth vidal 2009-03-12 10:23:14 EDT
what yum ver are you running now? -13 did just get built in rawhide a day ago.
Comment 16 Andrew Hecox 2009-03-12 11:19:47 EDT
yum-3.2.21-13.fc11.noarch
Comment 17 seth vidal 2009-03-12 11:28:26 EDT
Then, yes, quite a few things changed. Mostly a number of bugfixes.

If the bug doesn't come back then lets consider closing this.
Comment 18 Andrew Hecox 2009-03-12 11:31:42 EDT
sounds good. I'll test on the next kernel drop and close if it works. We can always re-open...
Comment 19 Andrew Hecox 2009-03-17 10:07:43 EDT
hmmm.

 # yum -y upgrade 

failed with the same error

 # yum clean all
 # yum -y upgrade

succeeded. Is that fixed?
Comment 20 Andrew Hecox 2009-03-17 10:09:10 EDT
n/m, I was wrong, it's still just broke. Attaching yum interaction.
Comment 21 Andrew Hecox 2009-03-17 10:09:58 EDT
Created attachment 335527 [details]
yum clean all && yum -y upgrade failure
Comment 22 James Antill 2009-03-17 10:26:39 EDT
Ok, from the output in comment#12 we see:

Installing:
 kernel                   i586    2.6.29-0.258.rc8.git2.fc11  rawhide     21 M
 kernel-devel             i586    2.6.29-0.258.rc8.git2.fc11  rawhide    6.1 M
Updating:
[...]
 kernel-debuginfo         i586    2.6.29-0.258.rc8.git2.fc11  rawhide-debuginfo
                                                                         303 M
 kernel-debuginfo-common  i686    2.6.29-0.258.rc8.git2.fc11  rawhide-debuginfo
[...]
Updating for dependencies:
 kernel-debuginfo-common  i586    2.6.29-0.258.rc8.git2.fc11  rawhide-debuginfo

...so you have two arches of kernel-debuginfo-common installed, and rpm is complaining that the .i586 arch of that pkg doesn't have it's deps. installed. Which yum doesn't check.

package-cleanup --dupes

...should solve this ... if not use: yum list kernel\* ... and manually remove one of the arches?
Comment 23 Andrew Hecox 2009-03-17 10:40:34 EDT
ahecox@t61 ~ $ package-cleanup --dupes
Setting up yum
Loaded plugins: dellsysidplugin2, refresh-packagekit
ahecox@t61 ~ $ 

ahecox@t61 ~ $ rpm -qa | grep kernel-debuginfo
kernel-debuginfo-2.6.29-0.237.rc7.git4.fc11.i586
kernel-debuginfo-common-2.6.29-0.237.rc7.git4.fc11.i586
ahecox@t61 ~ $ 

ahecox@t61 ~ $ yum -v check-update
Not loading "blacklist" plugin, as it is disabled
Loading "dellsysidplugin2" plugin
Loading "refresh-packagekit" plugin
Not loading "whiteout" plugin, as it is disabled
Config time: 0.230
Yum Version: 3.2.21
Setting up Package Sacks
pkgsack time: 0.115
rpmdb time: 0.000
Building updates object
up:Obs Init time: 0.133
up:simple updates time: 0.278
up:obs time: 0.006
up:condense time: 0.000
updates time: 2.805

anaconda.i586                   11.5.0.31-1                    rawhide          
fontconfig.i586                 2.6.99.behdad-3.fc11           rawhide          
fontconfig-devel.i586           2.6.99.behdad-3.fc11           rawhide          
freetype.i586                   2.3.9-1.fc11                   rawhide          
freetype-devel.i586             2.3.9-1.fc11                   rawhide          
gdm.i586                        1:2.25.2-20.fc11               rawhide          
gdm-user-switch-applet.i586     1:2.25.2-20.fc11               rawhide          
grubby.i586                     6.0.81-1.fc11                  rawhide          
kernel.i586                     2.6.29-0.258.rc8.git2.fc11     rawhide          
kernel-debuginfo.i586           2.6.29-0.258.rc8.git2.fc11     rawhide-debuginfo
kernel-debuginfo-common.i686    2.6.29-0.258.rc8.git2.fc11     rawhide-debuginfo
kernel-devel.i586               2.6.29-0.258.rc8.git2.fc11     rawhide          
kernel-firmware.noarch          2.6.29-0.258.rc8.git2.fc11     rawhide          
kernel-headers.i586             2.6.29-0.258.rc8.git2.fc11     rawhide          
libbdevid-python.i586           6.0.81-1.fc11                  rawhide          
libselinux.i586                 2.0.79-1.fc11                  rawhide          
libselinux-python.i586          2.0.79-1.fc11                  rawhide          
libselinux-utils.i586           2.0.79-1.fc11                  rawhide          
mkinitrd.i586                   6.0.81-1.fc11                  rawhide          
nash.i586                       6.0.81-1.fc11                  rawhide          
pango.i586                      1.24.0-1.fc11                  rawhide          
pango-devel.i586                1.24.0-1.fc11                  rawhide          
xorg-x11-server-Xorg.i586       1.6.0-13.fc11                  rawhide          
xorg-x11-server-common.i586     1.6.0-13.fc11                  rawhide         
ahecox@t61 ~ $ 
 

ahecox@t61 ~ $ sudo yum deplist kernel-debuginfo
Loaded plugins: dellsysidplugin2, refresh-packagekit
Finding dependencies: 
package: kernel-debuginfo.i586 2.6.29-0.258.rc8.git2.fc11
  dependency: kernel-debuginfo-common-i586 = 2.6.29-0.258.rc8.git2.fc11
   provider: kernel-debuginfo-common.i586 2.6.29-0.258.rc8.git2.fc11
ahecox@t61 ~ $ 

$ yumdownloader kernel-debuginfo
Loaded plugins: dellsysidplugin2, refresh-packagekit
kernel-debuginfo-2.6.29-0.258.rc8.git2.fc11.i586.rpm                                     | 303 MB     00:48   
ahecox@t61 ~ $ rpm -q --requires kernel-debuginfo
kernel-debuginfo-common-i586 = 2.6.29-0.237.rc7.git4.fc11
rpmlib(VersionedDependencies) <= 3.0.3-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1

I don't see where the the i686 version is coming from... ?
Comment 24 Andrew Hecox 2009-03-17 10:51:19 EDT
maybe interesting, if I just try and update kernel-debuginfo-common, yum seems to report it's updating the i686 version, even though that's not what's installed according to rpm. I rebuilt the rpm database, just in case, but the behaviour is the same:

ahecox@t61 ~ $ sudo yum update kernel-debuginfo-common
Loaded plugins: dellsysidplugin2, refresh-packagekit
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package kernel-debuginfo-common.i686 0:2.6.29-0.258.rc8.git2.fc11 set to be updated
--> Processing Dependency: kernel-debuginfo-common-i586 = 2.6.29-0.237.rc7.git4.fc11 for package: kernel-debuginfo
--> Running transaction check
---> Package kernel-debuginfo.i586 0:2.6.29-0.258.rc8.git2.fc11 set to be updated
--> Processing Dependency: kernel-debuginfo-common-i586 = 2.6.29-0.258.rc8.git2.fc11 for package: kernel-debuginfo
--> Running transaction check
---> Package kernel-debuginfo-common.i586 0:2.6.29-0.258.rc8.git2.fc11 set to be updated
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================================================
 Package                        Arch        Version                              Repository                Size
================================================================================================================
Updating:
 kernel-debuginfo-common        i686        2.6.29-0.258.rc8.git2.fc11           rawhide-debuginfo         36 M
Updating for dependencies:
 kernel-debuginfo               i586        2.6.29-0.258.rc8.git2.fc11           rawhide-debuginfo        303 M
 kernel-debuginfo-common        i586        2.6.29-0.258.rc8.git2.fc11           rawhide-debuginfo         36 M

Transaction Summary
================================================================================================================
Install      0 Package(s)         
Update       3 Package(s)         
Remove       0 Package(s)         

Total size: 375 M
Is this ok [y/N]:
Comment 25 seth vidal 2009-03-17 11:01:11 EDT
a couple more bits of info:

yum list installed kernel\*

uname -a

repoquery -q --provides kernel-debuginfo

thanks
Comment 26 Andrew Hecox 2009-03-17 11:11:30 EDT
ahecox@t61 ~ $ uname -a
Linux t61 2.6.29-0.237.rc7.git4.fc11.i586 #1 SMP Wed Mar 11 18:55:21 EDT 2009 i686 i686 i386 GNU/Linux

^^^^ ^^^^ !! 

ahecox@t61 ~ $ sudo repoquery -q --provides kernel-debuginfo
kernel-debuginfo = 2.6.29-0.258.rc8.git2.fc11
kernel-debuginfo(x86-32) = 2.6.29-0.258.rc8.git2.fc11
kernel-debuginfo-i586 = 2.6.29-0.258.rc8.git2.fc11

ahecox@t61 ~ $ yum list installed kernel\*
Loaded plugins: dellsysidplugin2, refresh-packagekit
Installed Packages
kernel.i586                                         2.6.29-0.215.rc7.fc11                              installed
kernel.i586                                         2.6.29-0.218.rc7.git2.fc11                         installed
kernel.i586                                         2.6.29-0.237.rc7.git4.fc11                         installed
kernel-debuginfo.i586                               2.6.29-0.237.rc7.git4.fc11                         installed
kernel-debuginfo-common.i586                        2.6.29-0.237.rc7.git4.fc11                         installed
kernel-devel.i586                                   2.6.29-0.215.rc7.fc11                              installed
kernel-devel.i586                                   2.6.29-0.218.rc7.git2.fc11                         installed
kernel-devel.i586                                   2.6.29-0.237.rc7.git4.fc11                         installed
kernel-doc.noarch                                   2.6.29-0.215.rc7.fc11                              installed
kernel-firmware.noarch                              2.6.29-0.237.rc7.git4.fc11                         installed
kernel-headers.i586                                 2.6.29-0.237.rc7.git4.fc11                         installed
kerneloops.i586                                     0.12-4.fc11                                        installed
ahecox@t61 ~ $ uname -a
Comment 27 James Antill 2009-03-17 15:47:50 EDT
Ok, I've reproduced this. It kind of sucks.

 in _requiringFromTransaction() we get to:

        # try updating the already install pkgs
        for pkg in provSack.returnNewestByName():
            results = self.update(requiringPo=requiringPo, name=pkg.name,
                                  epoch=pkg.epoch, version=pkg.version,
                                  rel=pkg.rel)

...here provSack just contains kernel-debuginfo-<ver>.i586 however the above update() call doesn't contain the arch ... so we decide to pick i686 over i586, we then install that that but fall out of that loop because the test:

                if pkg == txmbr.po:

...doesn't succeed. We then eventually decide kernel-debuginfo-<ver>.i586 is best after all, and install that too.

 So we can:

1. Pass arch to .update() above (tested and works).

2. Remove any txmbrs in results if we don't pass the test.

...now #1 fails horrible if we do it for all pkgs (make check has spasms), we can work around that by testing for allowedMultipleInstalls() and only passing arch then (but that might just be lack of test cases ... not sure).
 The second one is untested, and probably also fails in weird and wonderful ways. Proposed patch:

diff --git a/yum/depsolve.py b/yum/depsolve.py
index 2061376..da7f71a 100644
--- a/yum/depsolve.py
+++ b/yum/depsolve.py
@@ -535,9 +535,14 @@ class Depsolve(object):
 
         # try updating the already install pkgs
         for pkg in provSack.returnNewestByName():
-            results = self.update(requiringPo=requiringPo, name=pkg.name,
-                                  epoch=pkg.epoch, version=pkg.version,
-                                  rel=pkg.rel)
+            if self.allowedMultipleInstalls(pkg):
+                results = self.update(requiringPo=requiringPo, name=pkg.name,
+                                      epoch=pkg.epoch, version=pkg.version,
+                                      arch=pkg.arch, rel=pkg.rel)
+            else:
+                results = self.update(requiringPo=requiringPo, name=pkg.name,
+                                      epoch=pkg.epoch, version=pkg.version,
+                                      rel=pkg.rel)
             for txmbr in results:
                 if pkg == txmbr.po:
                     checkdeps = True

...what do you think Seth?
Comment 28 James Antill 2009-03-17 15:54:19 EDT
 It's worth noting that .update() is updating from kernel-blah.i586 to kernel-blah.i686 ... on the dep. processing path for kernel-blah-i586 ... which _only_ kernel-blah.i586 provides.
 So another fix could be to pass a required_dep argument to .update(), and that'd then reject kernel-blah.i686 because it doesn't provide that dep.
Comment 29 seth vidal 2009-03-17 17:15:52 EDT
a couple of questions for the kernel people - 

why do we have kernel-debuginfo-common.i686 at all? why not kernel-PAE-debuginfo-common.i686?
Comment 30 James Antill 2009-03-18 09:43:54 EDT
 I did the required_provides patch, to see what it looks like. And it does solve the problem, in a slightly less ugly way. However it breaks testFakeMultilibReqsUpdate2() because you have:

 pkgA requires libfoo.so()(64bit)

...and do "update pkgA", at which point yum doesn't want to update libfoo.i?86 anymore as it doesn't pass the required_provides filter ... except here we to do the opposite of the kernel-debuginfo desire (update one updates both).
 We could go into canCoinstall() land, but it'd be much more fun if we could just fix the kernel packaging.

 Putting into NEEDINFO for the kernel question.
Comment 31 seth vidal 2009-03-18 15:16:31 EDT
Over to kernel-maint
Comment 32 Roland McGrath 2009-03-18 16:42:33 EDT
For each arch, there is only one kernel-debuginfo-common.  That's what it's for.  Whatever variants come or go in the default build, kernel-debuginfo-common is common across them.
Comment 33 seth vidal 2009-03-23 10:16:04 EDT
Roland,
 Why? The problem we're having is that the arch being reported from uname() is i686 even when running on an i586 kernel. So this means that yum is preferring the i686 kernel-debuginfo-common over the i586 one despite there not being an i686 kernel.

This feels like a packaging problem and I think it should be fixed in the package.

Thanks
-sv
Comment 34 Roland McGrath 2009-03-23 16:02:08 EDT
"Why?" about choices of a given package is not at all apropos to why yum is failing to do the right thing.  It doesn't matter why we decided to have a subpackage.  You're not handling it properly.

There is a require/provide between the two packages that includes the arch.
kernel-debuginfo-common-i586 = 2.6.29-0.258.rc8.git2.fc11
Fill that requirement and you have the right packages.
Comment 35 Chuck Ebbert 2009-04-10 23:22:44 EDT
(In reply to comment #33)
> Roland,
>  Why? The problem we're having is that the arch being reported from uname() is
> i686 even when running on an i586 kernel. So this means that yum is preferring
> the i686 kernel-debuginfo-common over the i586 one despite there not being an
> i686 kernel.
> 
> This feels like a packaging problem and I think it should be fixed in the
> package.
> 

How would that be accomplished ??

Relying on uname() to detect the running kernel is just wrong.
Comment 36 Kyle McMartin 2009-04-11 10:35:28 EDT
(In reply to comment #35)
> 
> Relying on uname() to detect the running kernel is just wrong.  

Only relying on the 'uname' arch strings is wrong... 'uname -r' tells you which kernel you're running quite fine. And if you build your own, well, that's not really our problem since we aren't shipping debuginfo for it.
Comment 37 seth vidal 2009-04-13 13:25:33 EDT
*** Bug 495527 has been marked as a duplicate of this bug. ***
Comment 38 James Antill 2009-04-13 13:48:03 EDT
> "Why?" about choices of a given package is not at all apropos to why yum is
> failing to do the right thing.  It doesn't matter why we decided to have a
> subpackage.  You're not handling it properly.

 Not handling it "properly" is a loaded statement. From the other point of view the kernel is doing "cute" things with deps. and those don't work out so well.
 See comment #27 and comment #30

> There is a require/provide between the two packages that includes the arch.
> kernel-debuginfo-common-i586 = 2.6.29-0.258.rc8.git2.fc11
> Fill that requirement and you have the right packages.

 Yes, you do have deps. that could be sovled by a SAT solver ... but yum is not one. And from it's POV you have the same package name "kernel-debuginfo-common" for two arches (i586 and i686) which aren't the _same_ and can't be resolved using the usual arch detection logic (i686 on i686, i586 on i586, etc.).

 If there was a reason that you must do this, we can solve it by doing the comment #30 change, and then solving the multilib. problems. That's unlikely to happen for F11 though ... and I still haven't seen any reason that you need to make kernel-debuginfo-common-PAE be called kernel-debuginfo-common other than you decided to be cute and want us to make it work.
Comment 39 James Antill 2009-04-13 13:49:13 EDT
Also, is it possible to need both the .i586 and .i686 versions (installed kernel and kernel-PAE?) ... this is unlikely to work with just the arch. as the difference.
 Setting to NEEDINFO for questions in comment #38
Comment 40 Roland McGrath 2009-04-13 13:58:57 EDT
Yes, it is a realistic use case to have any number of different version and arch variants (and variant subpackages) of debuginfo installed for many kernels.  The directory names used in these packages include the arch name, so they do not conflict.

Re comment#38, sorry, I just don't buy your excuses for punting.  The package has correct deps and the purpose of yum is to resolve deps based on the dependency magic in the rpm headers.
Comment 41 James Antill 2009-04-13 14:08:21 EDT
> Yes, it is a realistic use case to have any number of different version and
> arch variants (and variant subpackages) of debuginfo installed for many
> kernels.

 I was not aware that realistic meant:

. Completely different semantics to every other package anywhere.

. Doesn't work, and has no fully working (no regressions) patches to make it even attempt to work.

. Likely doesn't actually work in all cases, even if we solve the current problem.

...but then I didn't ask _is it realistic_, I asked "what is the reason you are doing this instead of the obvious, and working, alternative to have different packages be named differently".
 So can you answer this?
Comment 42 Bill Nottingham 2009-04-13 14:45:59 EDT
(In reply to comment #41)
> ...but then I didn't ask _is it realistic_, I asked "what is the reason you are
> doing this instead of the obvious, and working, alternative to have different
> packages be named differently".
>  So can you answer this?  

They're not different? Maybe I'm not understanding what you're asking, but the entire idea of the -common semantics is that it's shared files for all kernel builds for an arch. So, it contains the shared files for kernel-PAE, kernel-debug, kernel-smp, kernel-ITurnedOnCrazyDriversInStaging, and whatever other variants might pop out of a kernel build. So renaming it kernel-debuginfo-common-PAE is nonsensical; if you went down that road, you'd have separate debuginfo builds for each kernel-<foo> subpackage entirely, which means you'd be shipping a copy of the source tree in each debuginfo source package, wasting a bunch of space.

Yes, it's unusual in that you can have multiple subarches of the same package installed. However, isn't that mainly unusual in that for most 'normal' package, you'd never be able to do that without file conflicts?
Comment 43 Roland McGrath 2009-04-13 14:50:18 EDT
This discussion seems to be going in circles and devolving into posturing rather than problem-solving.  Bugzilla is a lousy forum for discussion.  If you want to discuss the kernel packaging choices, let's take that up on fedora-kernel-list.
Comment 44 James Antill 2009-04-13 15:48:43 EDT
> They're not different? Maybe I'm not understanding what you're asking, but the
> entire idea of the -common semantics is that it's shared files for all kernel
> builds for an arch.

 If the .i586 and .i686 packages weren't different then I assume they wouldn't have two packages and specifically request one of them.
 Which is what I'm trying to find out ... how are these packages different, and why split them based on just arch instead of package name?

> Yes, it's unusual in that you can have multiple subarches of the same package
> installed. However, isn't that mainly unusual in that for most 'normal'
> package, you'd never be able to do that without file conflicts?  

 Well it's unusual in that noone has ever tested what yum does when you have pkgA.i586 and pkgB.i686 and I wouldn't like to bet a lot of money that it always works.
 All previous assumptions where that packages with the same name but different sub-arches (Eg. i386, i486, i586 and i686) all contained the same prco data, and we should pick based on uname (glibc, openssl, etc).

> This discussion seems to be [...] devolving into posturing rather
> than problem-solving

 I'm not posturing, I'm just stating that it's not an easy problem you are asking us to solve. And it's not a great point in time (for F11) to introduce significant changes to how yum treats arch/sub-arch/multilib ... and I say this after writing and testing about 4 different patches, to just make the weird stuff you are doing work without caring why it's done, so I can get back to doing something useful.
 So ... still trying to find out: why are you doing this?
Comment 45 Kyle McMartin 2009-04-13 16:17:42 EDT
kernel-debuginfo-common is effectively just a copy of the source tree... There's no particularly reason we couldn't make it common between i586 and i686. Or, for that matter, include the rest of the stuff we don't build, and make it noarch. (kernel-debuginfo-common strips all the headers and arch/* from arches besides the one we built.)
Comment 46 Chuck Ebbert 2009-04-13 19:33:47 EDT
(In reply to comment #44)
>  So ... still trying to find out: why are you doing this?  

We're doing it to save space. (The -common package used to be part of the debuginfo package.) And it's been separate for many Fedora releases...
Comment 47 Roland McGrath 2009-04-13 19:48:32 EDT
Re comment #45: Kyle does not really know how this is generated and what the issues are, or at least I bet he has not volunteered the patch to make it work the way he describes (one that really works really right, that is).

This is, of course, a likewise utterly untenable time in the cycle to be fiddling with the hairy kernel packaging magic in giant ways.

Given the problem here is about upgrade, not about any problem (AFAIK) having all the things one might reasonably want installed simultaneously to be so installed, I don't think you need to consider this is a huge priority for yum if it's difficult to do correctly.  (Forgive me for boggling at how any methodology other than one that would cover this could ever have been correct in the general case.)  I believe "yum remove kernel-debuginfo; yum install kernel-debuginfo" (or whatever) will be a tolerable work-around until some time after the F11 release if need be--regular users already have to contort themselves to enable the debuginfo repo anyway.
Comment 48 James Antill 2009-04-13 22:58:37 EDT
(In reply to comment #46)
> (In reply to comment #44)
> >  So ... still trying to find out: why are you doing this?  

> We're doing it to save space. (The -common package used to be part of the
> debuginfo package.) And it's been separate for many Fedora releases...

 Yes, I understand why you have a -common package.

 Ok, let me try to explain my question.

 On an i386 repo. let's consider just the 6 packages:

1. kernel.i586                  :  21M
2. kernel-PAE.i686              :  21M
3. kernel-debuginfo.i586        : 296M
4. kernel-PAE-debuginfo.i686    : 299M
5. kernel-debuginfo-common.i586 :  36M
6. kernel-debuginfo-common.i686 :  36M

...now I understand why you want the first 4, and I understand the idea behind a "common" package to save the 10% of space between varients.
 However these are the bits that confuse me:

  i. Why do there need to be two "common" packages, can't you just have one and put the non-common bits in their respective non-common packages (#3 and #4)? (as I read it, this is the bit Kyle implied could be fixed).

 ii. Assuming you do need two, why are they both called kernel-debuginfo-common and one of them not called kernel-debuginfo-common-PAE (or whatever)?

...also as an addon question do you expect to be able to do:

   yum install kernel-debuginfo kernel-PAE-debuginfo

...and have it work. I think the answer is yes, but I just want to make sure.
Comment 49 Andrew Hecox 2009-04-14 00:25:57 EDT
re: issue severity. whatever I filed it at, I was pretty lazy about it -- IIRC, it was at least a month before I registered the bug.

That said, if you want to use oprofile or systemtap with rawhide (maybe less with fedora 11 proper) this bug is a major PITA. I'm not sure how niche stap usage is in Fedora, but I'm sure we'd like to see it grow.

Again, my perspective is biased here since I'm running rawhide, but I don't think the use-case of rawhide+systemtap is a bad one to encourage. It'd certainly suck to see this get into F11 as-is.
Comment 50 James Antill 2009-04-14 02:10:04 EDT
 Some more data from some testing (all from with nothing installed, unless specified):

1. If you run "debuginfo-install kernel", then it installs kernel-debuginfo-common.i586. Dito yum install kernel-debuginfo.

2. If you run "yum install kernel-debuginfo-common" it installs the .i686 version.

3. If you run "yum install kernel-debuginfo-common.i586 kernel-debuginfo-common.i686" ... then yum tries to install both, but rpm only installs the .i586 version (although it thinks it only installed the .i686 version).

4. If you run "yum install kernel-debuginfo-common.i686" after you've installed kernel-debuginfo-common.i586 then yum tries to do it, but rpm says "kernel-debuginfo-common.i686 already installed" and fails the transaction (presumably a similar message the other way around).
Comment 51 Bill Nottingham 2009-04-14 13:25:15 EDT
(In reply to comment #48)
> ...now I understand why you want the first 4, and I understand the idea behind
> a "common" package to save the 10% of space between varients.
>  However these are the bits that confuse me:
> 
>   i. Why do there need to be two "common" packages, can't you just have one and
> put the non-common bits in their respective non-common packages (#3 and #4)?
> (as I read it, this is the bit Kyle implied could be fixed).

debuginfo is generated per-arch. Having a common bit for all arches would be deep nasty specfile goo.

>  ii. Assuming you do need two, why are they both called kernel-debuginfo-common
> and one of them not called kernel-debuginfo-common-PAE (or whatever)?

kernel-debuginfo-common.<ARCH> is the common debuginfo for *all* kernels built for that arch. You could have, for any one arch:

- <base, no modifier>
- PAE
- SMP
- debug
- SMPdebug
- PAEdebug
- etc.

So, it should be named without any specific modifier, since it covers all possible kernel builds. Having it named kernel-debguginfo-common-PAE when it would also apply to a SMP kernel, or a debug kernel, doesn't make sense.
Comment 52 Andrew Hecox 2009-04-14 13:59:59 EDT
stupid user question: if there's no kernel.i686 nor kernel-debuginfo.i686, why is there a kernel-debuginfo-common.i686? which kernel/kernel-debuginfo package is it supporting?
Comment 53 Bill Nottingham 2009-04-14 14:25:13 EDT
kernel-debuginfo-common.<arch> supports *all* kernel(-<whatever>)-debuginfo.<arch> packages. It just happens in the current i686 build, that is only -PAE. Prior to F11, it was kernel and kernel-PAE... if you go back far enough, there was a -hugemem and an -enterprise variant too.
Comment 54 Andrew Hecox 2009-04-14 15:33:08 EDT
we have a i686 build? that's my confusion. I only have two i686 packages...
Comment 55 Bill Nottingham 2009-04-14 15:49:28 EDT
An i686 build of the kernel package, yes. It's one of a few packages we build for non-default architectures.
Comment 56 Andrew Hecox 2009-04-14 16:45:45 EDT
thanks
Comment 57 Chuck Ebbert 2009-04-15 11:30:50 EDT
(In reply to comment #52)
> stupid user question: if there's no kernel.i686 nor kernel-debuginfo.i686, why
> is there a kernel-debuginfo-common.i686? which kernel/kernel-debuginfo package
> is it supporting?  

But there are kernel-PAEdebug.i686 and kernel-PAEdebug-debuginfo.i686 packages.
Comment 58 William Cohen 2009-04-15 14:09:30 EDT
It seems odd that yum will correctly install a i586 version of the kernel-debuginfo and kernel-debuginfo-common based with just "yum install kernel-debufinfo". Then doing the upgrade where the i586 versions are already on the machine it gets things wrong and tries to install the i686 version. Why would yum even consider pulling in a i686 version of a kernel-debuginfo-common package?
Comment 59 Chuck Ebbert 2009-04-15 16:34:37 EDT
(In reply to comment #58)
> It seems odd that yum will correctly install a i586 version of the
> kernel-debuginfo and kernel-debuginfo-common based with just "yum install
> kernel-debufinfo". Then doing the upgrade where the i586 versions are already
> on the machine it gets things wrong and tries to install the i686 version. Why
> would yum even consider pulling in a i686 version of a kernel-debuginfo-common
> package?  

It is using uname() to determine what arch to install.
Comment 60 Kyle McMartin 2009-04-15 20:21:56 EDT
Well, that's the bug then... It should be parsing uname -r, not using any of the uname "machtype" fields.
Comment 61 Roland McGrath 2009-04-15 22:02:16 EDT
uname -r is wholly unrelated.  It's upgrading an rpm that is installed.  There is nothing magically kernel-related about what it is and should be doing.  It's just the question of what "upgrade foo-debuginfo" means when installed foo-debuginfo-1.subarch1 and available foo-debuginfo-2.subarch2 (and both subarch[12] are installable here, I guess).  I don't actually care whether it decides to switch from i586 to i686 or vice versa for upgrading kernel-debuginfo, that's a sort of yum UI question I guess.  The only hard issue IMHO is that once it has decided what kernel-debuginfo (really kernel-PAE-debuginfo I guess) to upgrade, it should follow the deps to upgrade the kernel-debuginfo-common of the same arch.

The kernel*-debuginfo <-> kernel-debuginfo-common deps were set up before the recent rpm versions that do some kind of .arch version tags now.  I don't know if it would work better or differently if we tweaked the dependencies it generates.
Comment 62 James Antill 2009-04-16 00:12:34 EDT
 I'm unsure of how much use this post is given that noone seems to have responded to the fact that, even if we fixed yum to work in this specific case just for the kernel ... _rpm_ can't handle it.
 Probably for much the same reasons, in that no other package that I can find has different prco data for different sub-arches. It's just not done, and it's assumed to not be done, to implement other features that everyone uses.


 But, anyway, assuming you must have it be "generic" an obvious change is to have the arch in the name:

kernel-debuginfo-common-i586.i586
kernel-debuginfo-common-i686.i686

...it makes an ugly package name, but it'll work with rpm and yum/apt/smart/etc.
Comment 63 Roland McGrath 2009-04-16 02:35:47 EDT
We already have requires/provides of exactly those names (kernel-debuginfo-common-%{_target_cpu}).

kernel-debuginfo-common is intended entirely as a subordinate package that users don't need to think about directly because the deps make kernel*-debuginfo get all the right stuff.  I don't think we care how ugly its name is.  Last I knew all the distro stuff cares about is that it has "debuginfo" somewhere in the name and it will wind up in the right repo.
Comment 64 Roland McGrath 2009-04-16 02:37:51 EDT
Created attachment 339794 [details]
kernel.spec patch

Haven't tried it, that kernel.spec change should rename kernel-debuinfo-common to kernel-debuginfo-common-ARCH and nothing else should care.  The existing requires: matches the removed provides: that now matches the default package name provide.
Comment 65 Bug Zapper 2009-06-09 07:42:11 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 66 Andrew Hecox 2009-06-11 10:55:07 EDT
did Roland's patch get applied? tried? 

still broke here moving from 2.6.29.4-167 to 2.6.30-0.97.rc8
Comment 67 Mark Wielaard 2009-08-06 08:01:43 EDT
Still broken trying to upgrade to 2.6.29.6-217.2.3.fc11.

See also upstream yum bug report (which says this is a fedora kernel packaging bug): http://yum.baseurl.org/ticket/175

This is particularly annoying when you have the yum auto-update-debuginfo plugin enabled to keep all debuginfo packages up to date with.
Comment 68 Mark Wielaard 2009-08-16 05:03:13 EDT
Still an issues with recent F11 kernels:

ERROR with rpm_check_debug vs depsolve:
kernel-debuginfo-common-i586 = 2.6.29.6-217.2.7.fc11 is needed by kernel-debuginfo-2.6.29.6-217.2.7.fc11.i586
Please report this error at http://yum.baseurl.org/report
Comment 69 Bug Zapper 2010-04-27 09:04:06 EDT
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 70 Bug Zapper 2010-06-28 07:21:41 EDT
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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