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

-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Reply via email to