[elrepo] Announcement: EL7 Updated kmod-nvidia package for RHEL7.6

[Phil Perry]

<snipped>

> On 2018-11-09 2:07 a.m., Phil Perry wrote:
>>
>> We have been looking at technical solutions to this issue for a long time. I
>> tried to write a yum plugin to prevent yum offering packages where the
>> prerequisite kernel requirements could not be met, but unfortunately my python
>> skills are not quite up to the job (we would welcome contributions here from
>> anyone with python experience).
>>

OK, I've had some success in writing a yum plugin which I've uploaded to 
the elrepo-testing repository (should be available shortly) for folks to 
test:

yum-plugin-elrepo-7.5.0-1.el7.elrepo.noarch.rpm

Code is available here:

https://github.com/elrepo/packages/tree/master/yum-plugin-elrepo


Lets first define the issue we are trying to solve:

At point releases, some kmod packages require rebuilding against the 
latest RHEL kernel. The resulting kmod packages *Require* the new RHEL 
kernel. This can cause dependency errors in yum when clone distros such 
as CentOS and Scientific Linux have yet to catch up and release their 
corresponding point release kernels.

This plugin determines the kernel a kmod package is built against, and 
will exclude (hide) it from yum if the corresponding kernel is not (yet) 
available. Once the corresponding kernel becomes available, so will the 
kmod package(s) that require it.

However, there is one issue here, due to a major difference between the 
way yum works on RHEL and it's clones. On RHEL, *all* previous kernels 
are available to yum. This is not the case by default on CentOS, where 
only kernels from the current point release are available.

Consequently, the plugin as described above would exclude (hide) from 
yum any kmod package built against an earlier kernel (e.g, 7.0) that 
remains compatible as the plugin can not find the required earlier 
kernel version on CentOS (and SL?). This is obviously not the intention.

The solution to this is either:

1. set up your repos to mimic how RHEL works, i.e, make all kernels 
available to yum, or

2. for now, I have temporarily excluded all older kmod packages, as 
identified by their dist tag (e.g, el7.elrepo, el7_4.elrepo, 
el7_5.elrepo) as we are really only interested in packages for the new 
point release (currently el7_6.elrepo).

In the future I may deprecate/remove this feature so the plugin will 
only work (correctly) if all kernels are available, but I'd like some 
discussion about how best to handle this. I believe option (1) is more 
robust than any fudge / workaround I can implement and will allow the 
plugin to work seamlessly going forward, including on unsupported setups 
where people have stayed on older point releases. It doesn't matter 
whether we are talking now, transitioning from el7.5 to el7.6, or 6-12 
months from now transitioning from el7.6 to el7.7, or for someone who 
for whatever reason has stayed on el7.4 (or whatever point release). The 
plugin should just work in all scenarios as long as all kernels are 
available to yum (in reality it doesn't even need to be all kernels, 
just the base kernel from each point release).

The technical reason we find ourselves in the pickle above is that the 
plugin is only working at the package version level - i.e, kmod-foo 
requires kernel-version-release, and if kernel-version-release is not 
available because it's from an older point release then kmod-foo is 
excluded. The plugin code currently only evaluates matches (it's 
actually a string match) so can not parse greater than.

Normally yum works by resolving individual package requires. However 
this is simply not practical in this case. We would need to check every 
required kernel symbol for every kmod package in the repo(s) against 
those provided by every kernel for a match. Given there are currently 
163 kmod packages in elrepo with up to 400 kernel symbols each that 
would need matching against the 60 different kernels available on RHEL7, 
each in turn providing over 17,000 symbols every single time yum is run, 
it becomes readily apparent why trying to achieve this in a yum plugin 
is not practical. Maybe if yum was written in C, but written in python 
yum is not the fastest of beasts. This simple plugin as written already 
adds a couple seconds to each and every yum transaction.

> 
> I would love to contribute but my python experience is limited and writing yum
> plugin skill is existent.
> 
> They way I see it - a simple solution would be, for you to change how the repos
> work. The current way only support latest 7rolling, 7x on RHEL.
> Others like Scientific Linux does it as 7.2, 7.3, 7.4, 7.5 so some can freeze
> their install to a specific version.
> 

Sorry, that isn't going to happen. But as noted above, if you make all 
point release kernels available as RHEL does, the yum-plugin will 
support the above configuration.