Red Hat Bugzilla – Bug 129396
make rpm creates erroneous version number
Last modified: 2015-01-04 17:08:28 EST
Description of problem:
When using fc2 new "make rpm" target for compiling the kernel, the "-"
the seperates the bug release number from the major and minor numbers
is left out, leaving the kernel with a much high version number. I
noticed in the makefile, they include the "-" in the subversion, but
they don't include the "." in the major and minor which leaves me to
conclude that the inclusion of the "-" is conflicting with systems
automatic inclusion of a "." or "-" this has been tested on two
completely different i386 computers.
Version-Release number of selected component (if applicable):
I have tested the kernel-sourcecode "make rpm" target for
2.6.6-1.435.2.3 and 2.6.7-1.494.2.2
Steps to Reproduce:
followed these steps: http://www.fedoraforum.org/forum/article.php?a=4
1. install kernel-sourcecode
2. configure as usuall, nothing special and same config worked on
previous kernels using make bzImage && etc.
3. use "make rpm" to compile
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.74990
+ umask 022
+ cd /usr/src/redhat/BUILD
+ cd kernel-188.8.131.524.2.2custom
+ exit 0
Note the "-" between the 2.6.7 and the 1.494.2.2custum
that's most likely intentional from the folks who implemented make
rpm, you can't have more dashes the way you suggest. everything after
teh last dash HAS to be the release of the rpm, and everything before
it and the last-but-one dash is the "upstream" version.
So here the pacakge is called "kernel", the upstream (eg our version)
gets truncated to "184.108.40.2064.2.2custom" and the release is "1"
the real problem is that when you want to upgrade to a security fixed
kernel, it won't becuase it thinks you have a newer kernel installed.
2.6.71 is assumed larger than say 2.6.8. So yum and up2date updates
never succeed unless you do them manually.
I would suggest that you contact the make rpm person or ask on
email@example.com since this is more of a generic problem
than our problem, and, well, we ship a way to make "nice" rpms... it's
just not "make rpm" so I can't justify spending a whole lot of time
"fixing" make rpm, since the end isn't in sight that way.