I'd like to propose that we include the architecture in kernel version as well as we currently do with the kernel flavour (`smp', `hugemem' etc. for RHEL/CentOS, `PAE', `xen0' etc. for FC). Rationale: 1. It is technically possible (and also somehow reasonable -- debugging and/or development purposes for example) to have more than one kernel of the same flavour but different architecture. At last it is possible to run i586 kernel on an i686 machine. (Probably also i586 and i686 on an x86_64 and maybe others as well...). It is technically impossible to have such combination installed from stock RPMs, though. Because both i586 and i686 have the same name, the two RPMs will collide on file names (both for the kernel images as well as for the whole modules subdirectories). The filelists for the latest FC RPMs (`kernel-2.6.16-1.2227_FC6.i586.rpm' and `kernel-2.6.16-1.2227_FC6.i686.rpm') only differ in a few modules, but are otherwise the same. 2. We've already had a bug #149210 which arised from the above ambiguity. The kernel devel package can't know what arch is the kernel package that is already present in the system. It knows it's the same version as well as a flavour (that is, it doesn't know but can safely expect this as it is being in the appropriate directory), but can't know anything about it's arch. It just happily symlinked itself there not caring about such detail. 3. While moving these links to out of the package devel to the kernel one is a solution of the previous problem, it doesn't seem systematically correct to me. This results in dangling symlinks when the appropriate devel package isn't installed which is not pretty. In fact a bug #193477 appears to have been filed recently on this. Additionally, I believe it's nonsense for the links to exist even if they weren't dangling. Until there's a devel package actually installed, there's no reason for anything to point to kernel sources/headers which are not really installed. (Well yes, dangling symlinks are in fact nonexistent files, but they are *dangling* symlinks which is a pathologic thing itself. ;-) ) 4. The bug #145914 could get fixed from the principle and it would be no more required to explictly append the architecture when determining the correct subdirectory under `/src/kernels'. 5. Yes, this proposal would make the kernel name even longer. But I don't think the FC names are an example of brevity either (as is not this proposal -- sorry). Examples: Will demonstrate on the latest FC kernels mentioned above, but will also work with a hypothetical flavoured one. For the unflavoured kernel we now have: kernel RPM name: `kernel-2.6.16-1.2227_FC6.<arch>.rpm' kernel version (plus `/lib/modules' subdirectory name): `2.6.16-1.2227_FC6' `/src/kernels' subdirectory name" `2.6.16-1.2227_FC6-<arch>' For the flavoured kernel: kernel RPM name: `kernel-<flavour>-2.6.16-1.2227_FC6.<arch>.rpm' kernel version: `2.6.16-1.2227_FC6<flavour>' `/src/kernels' subdirectory name" `2.6.16-1.2227_FC6-<flavour>-<arch>' (plus a recently added symlink `2.6.16-1.2227_FC6<flavour>-<arch>' I'd suggest to use the kernel name in the form we currently use for the devel files, ie. those we use to name subdirectories under `/src/kernels'. That way we'd get the architecture directly into the kernel image name as well as modules directory name avoiding any potential conflicts. Now, since such a name is fully qualified, it could be also used for the devel files subdirectoty without any changes. I'd prefer the version with the dash (which was removed for the recently added symlink). So the result would be: kernel RPM name: `kernel-<flavour>-2.6.16-1.2227_FC6.<arch>.rpm' kernel version: `2.6.16-1.2227_FC6-<flavour>' `/src/kernels' subdirectory name" `2.6.16-1.2227_FC6-<flavour>-<arch>' (no symlink needed) So, the only thing thich differs is the RPM name itself, but that's from the principle of RPM naming and can be lived with. After all RPM name is quite unimportant when referencing installed kernel files. The names were shown for reference. While this may seem to be more drastical change than all the previously made, I believe this provides more systematic and consistent approach and solution of several recently discussed problems. Since this is filed against rawhide I believe it *is* the place where we could initiate such changes.
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.
Reporter clearly does not care any more.