[OE-core] [PATCH v3] kernel-module-split: Append KERNEL_VERSION string to kernel module name

[Ola Redell]

On 01/12/2017 02:44 PM, Bruce Ashfield wrote:
>
>
> Interesting. I think we've probably fallen off the radar of the casual 
> reader that may have
> more bitbake knowledge to explain why the virtual package 
> (kernel-modules) provides
> works with the same name and different versions, while a package with 
> the version postfix
> that rprovides the same name doesn't work with different versions.
>
I think I have a clue on this so let me try to straight it out as much 
as I can in a somewhat more structured manner than my earlier attempt, 
and hopefully with a readable formatting this time... I'll do a 
background and overview too to let new readers in. I am sorry about this 
being lengthy. I'll post a patch v4 based on the end conclusion.

Anyone with a better knowledge in package management than me (that means 
very many of you) might want to fill in or correct the below. And Bruce, 
I kept #1 and #3 separate since I see quite a difference between "meta 
packages" and "virtual packages".

In my current system I use deb packages and apt-get as package manager 
so the discussion below is apt-get centric. The *assumption* here is 
that package managers in general behave in a similar way to apt-get, 
when it comes to the details below.


Background

My use case is that I want a kernel module packaging that allows me to 
upgrade my kernel and kernel modules using a package manager such as 
apt-get without the kernel modules for the older kernel being removed. 
When I perform an upgrade today (either dist-upgrade or upgrade on the 
package "kernel-modules") the old modules are removed. My motivation is 
that I want to be able to fall back to the older kernel and its modules 
if necessary.

The "kernel-modules" package is called a "meta package" in the code. 
Even though it is an empty package (therefore "meta"), it is a package 
in its own right with a package version based on the kernel version used 
to build it. It has dependencies to all kernel module packages (e.g. 
kernel-module-foo) that are built by bitbake. Hence when the 
"kernel-modules" package is installed or upgraded it pulls in all those 
modules that it depends on.

Side note: If apt-get finds many "kernel-modules" packages available it 
simply picks the one with the latest version (unless given a specific 
version). So having many "meta packages" of different versions available 
at the same time is not a problem - apt-get can distinguish between them.

Today, the kernel module packages like kernel-module-foo are named the 
same regardless of what kernel they belong to. Hence kernel-module-foo 
for kernel-x is the same package as kernel-module-foo for kernel-y, just 
with another version. Therefore, when the "kernel-modules" package is 
upgraded, the new version of kernel-module-foo is installed while the 
older version is removed (you cannot have two versions of the same 
package installed at once). That is the problem.


Alternative solutions

My original suggestion (#0) was to just postfix the kernel module 
package names with a kernel version string (creating 
kernel-module-foo-<kversion>) just like what is done with the kernel 
itself already today. Note that this <kversion> has very little to do 
with the actual version of the package. <kversion> is just 
KERNEL_VERSION, nothing else. This solves my use case but causes other 
problems as Bruce pointed out. Existing recipes with dependencies to 
kernel-module-foo will break, and even worse, will have to be updated 
for every new kernel version.

One alternative (#1) would be to add the postfix and also add empty 
"meta packages" for all kernel-module packages, such that the meta 
package "kernel-module-foo" would depend on 
"kernel-module-foo-<kversion>". That would work great (presumably - 
untested), just like the "kernel-modules" meta package, but would add a 
lot of new packages to the already time consuming build. It would also 
make the kernel-module-split class even more complex.

Another alternative (#2) is to simply make the postfix configurable, on 
or off. This would work fine but it would also add to the complexity of 
the kernel-module-split code as well as adding another (rarely used) 
code path, with the effects that has on stability.

A third alternative (#3) is to add the postfix and let the kernel module 
packages RPROVIDE the shorter named package. Hence 
kernel-module-foo-<kversion> would then provide kernel-module-foo such 
that recipes can still depend on the kernel-module-foo which is now a 
"virtual package". A "virtual package" is more like an alias for the 
real package and is not a package in its own right (unlike the meta 
package). With this solution one would also be able to install 
kernel-module-foo using "apt-get install kernel-module-foo" but only if 
there is only one provider available. Hence, it would not be possible to 
"apt-get upgrade kernel-module-foo" to get 
kernel-module-foo-<kversion-2> since the original package 
(kernel-module-foo-<kversion-1>) is always available in an OE system(?) 
(afaik). This would not be a problem with the "kernel-modules" package 
which would depend on kernel-module-foo-<kversion> and friends.

The creation of the virtual packages in #3 would be made configurable 
such that it can be switched OFF, if one is not interested in keeping 
the old behavior. It would be ON by default.


Conclusion

The more I think of it, the more difficult it is to point out a best 
alternative. The currently agreed upon alternative is #3 with the 
virtual package, since #1 would generate such a large number of 
additional (meta) packages.

I will prepare a patch v4 and submit shortly. Since I am not a very 
experienced python hacker, feel free to help me optimize it.

Thanks,
Ola

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20170113/279afeac/attachment-0002.html>