Bug 193990

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.