[rhelv6-beta-list] kernel-release now appends the arch

[Jon Masters]

On Mon, 2010-05-03 at 19:51 +0200, Stephan Wiesand wrote:
> On Apr 30, 2010, at 23:31 , Ned Slider wrote:
> 
> > Stephan Wiesand wrote:
> >> On Apr 30, 2010, at 21:45 , Ned Slider wrote:
> >>> Stephan Wiesand wrote:
> >>>> On Apr 29, 2010, at 21:10 , inode0 wrote:
> >>> <snip>
> >>> 
> >>>>> I'm sympathetic to not liking changes that affect scripts and have
> >>>>> been bitten by changes in RHEL in the past but I don't really see a
> >>>>> use case where `uname -r` isn't still going to return the right
> >>>>> thing?! Maybe I'm not being imaginative enough.
> >>>> well, imagine an environment where external kernel modules are a necessity. Ok, they almost never really are, because almost always we could tell our users to get lost and use an OS that works for them. But, even setting aside the very few real cases where this actually isn't an option, I don't like the idea.
> >>>> So, please try to imagine you'd been maintaining a script that cares for updates of kernels *and* additional modules, making sure that each and every system that boots either comes up with the current kernel and all required modules available (Fedora/RHEL has *no* tool helping here - please prove me wrong) 
> >>> kmodtool for building kABI-tracking kernel independent kmod (kernel module) packages? But that uses 'uname -r' too ;)
> >>> 
> >>> Anyway, you don't need to be rebuilding modules against every kernel - build them once with kmodtool and be done with it. Or better still, put in an RFE request to a 3rd party repo like elrepo.org for the modules you require and let someone else maintain them for you.
> >> Right track, for sure. Alas, none of the modules I'm dealing with is using whitelisted ABIs only.  And btw, some of them are even closed source, I can't help it.

In RHEL5, due to technical limitations within RPM (and yum too), we had
to confine the RPM dependencies on the kernel to specific symbol groups.
And in so doing, we could only list in a given group symbols that were
not likely to change and cause the entire group - which is a SHA1 hash
of the members of the group - to break the kernel deps.

I've been itching to "fix" this ever since and in RHEL6 the kernel
package now has individual deps for each of the kernel symbols. So
whether or not something is "whitelisted" by us as part of our internal
process of working with partners and driver developers you can now use
all of the symbols and rely on the packaging to prevent the installation
of incompatible drivers, rather than using the various kludges that are
floating around and which rely on symbols that are "grey" (not likely to
change, but they might, and then you'd have a problem).

In fact, in RHEL6 there will likely eventually (it exists, but some
other work is ongoing and I am wording this so as to not set an
expectation of a commitment pre-GA) be a yum plugin that will also
facilitate kABI by allowing you to request that only kABI conforming
drivers be installed. The whitelists will just be separate data that is
independent from the kernel package.

Although I'm tied up with lots of RHEL6 stuff at the moment, please do
feel free to email me about driver packaging with regard to RHEL6,
especially if you are a partner, but also if you are an end user,
developer, or other beta tester!

Jon.