Bug 193990 - could the kernel version include architecture as well?
Summary: could the kernel version include architecture as well?
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Brian Brock
Whiteboard: bzcl34nup
Depends On:
TreeView+ depends on / blocked
Reported: 2006-06-04 01:21 UTC by Jiri TRAVNICEK, alias JITR {temporarily not reading bugmail}
Modified: 2008-04-03 17:22 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-04-03 17:22:02 UTC
Type: ---

Attachments (Terms of Use)

Description Jiri TRAVNICEK, alias JITR {temporarily not reading bugmail} 2006-06-04 01:21:18 UTC
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).


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).


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

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.

Comment 1 Bug Zapper 2008-04-03 17:18:23 UTC
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:

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

Comment 2 Warren Togami 2008-04-03 17:22:02 UTC
Reporter clearly does not care any more.

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