On 01/12/2017 02:44 PM, Bruce Ashfield wrote:
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.
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
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.
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.
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
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.
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.
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.
Openembedded-core mailing list