Bug 487731
| Summary: | yum update/upgrade fails if kernel-debuginfo is install (F11/Alpha) | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Andrew Hecox <ahecox> | ||||||
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | ||||||
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | 11 | CC: | fche, ffesti, james.antill, jonstanley, kernel-maint, kmcmartin, mjw, notting, pmatilai, roland, tim.lauridsen, wcohen | ||||||
| Target Milestone: | --- | Keywords: | Reopened | ||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2010-06-28 11:21:41 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
Andrew Hecox
2009-02-27 17:38:15 UTC
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. This should be fixed by the yum-plugin-auto-update-debuginfo package, should get into Fed-10 "soon". Until then just pass --enablerepo=\*debuginfo. Thanks James. Fed-10 or rawhide? 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 $ 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. 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. should I change the component to mirrormanager? 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. 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. thanks Matt -- I'll test next push and close once confirmed. 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). CURRENTRELEASE. Not really a code change, but needed to run MM's manage-repo-redirects script to add the prerelease redirects. 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']) $ and worked this time. - am I hopelessly confused? - is this random? - did a new fix go in? thanks. Andrew what yum ver are you running now? -13 did just get built in rawhide a day ago. yum-3.2.21-13.fc11.noarch Then, yes, quite a few things changed. Mostly a number of bugfixes. If the bug doesn't come back then lets consider closing this. sounds good. I'll test on the next kernel drop and close if it works. We can always re-open... hmmm. # yum -y upgrade failed with the same error # yum clean all # yum -y upgrade succeeded. Is that fixed? n/m, I was wrong, it's still just broke. Attaching yum interaction. Created attachment 335527 [details]
yum clean all && yum -y upgrade failure
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? 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... ? 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]: a couple more bits of info: yum list installed kernel\* uname -a repoquery -q --provides kernel-debuginfo thanks 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 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?
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. 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? 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. Over to kernel-maint 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. 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 "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. (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. (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. *** Bug 495527 has been marked as a duplicate of this bug. *** > "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. 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 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. > 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?
(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? 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. > 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? 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.) (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... 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. (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. 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. 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). (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. 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? 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. we have a i686 build? that's my confusion. I only have two i686 packages... An i686 build of the kernel package, yes. It's one of a few packages we build for non-default architectures. thanks (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. 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? (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. Well, that's the bug then... It should be parsing uname -r, not using any of the uname "machtype" fields. 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. 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. 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.
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.
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 did Roland's patch get applied? tried? still broke here moving from 2.6.29.4-167 to 2.6.30-0.97.rc8 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. 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 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 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. |