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

[Bruce Ashfield]

On Tue, Jan 10, 2017 at 3:44 AM, Ola Redell <ola.redell at gmail.com> wrote:

>
>
> On 01/09/2017 06:20 PM, Bruce Ashfield wrote:
>
>
> The functionality you describe is a good thing, but I have a few questions
> to make
> sure I understand the change, and confirm that existing functionality
> isn't broken ..
> and that the internals of the package management do the right thing (I'm
> not an
> expert on those internals .. so bear with me).
>
> I am not an expert either so I thought I'd suggest this since it works for
> me and see how it is received.
>


A good plan. It is always better to spur discussion with a tangible patch,
which it has done!


>
> With this change, do you know if RDEPENDS="kernel-module-foo" still works
> ? or
> does it now have to be RDEPENDS="kernel-module-foo-<version>" ?
>
> No, the old writing would not work. You would need to add the version as
> in your second example. That will break things, true.
>


ok. That was what I thought as well. As you noted, that is a problem since
it would now
mean that any recipe that wants to rrecommend or rdepend on a package no
longer has
kernel version flexibility (unless wildcards are in play) and not the
virtual/kernel type
binding that it may have had before.


> On a similar thought, "smart install kernel-module-foo" would also work ?
> or does it
> now require a version ?
>
> Also in this example you would need to add the version, even though I have
> only used apt-get and not smart.
>
> The meta package "kernel-modules" will work as before, without a version
> postfix.
>

As it turns out, I normally use the meta package myself, but I do know of
others that
don't use it, but do reference individual module packages.


>
> So basically, as I understand it, this may be a blocker for this change.
> Alternatives I can come up with are:
>
> 1) For all packaged kernel modules, add meta packages that depend on the
> correct version of the kernel module itself. Then "kernel-module-foo" would
> depend on "kernel-module-foo-<version>". The package "kernel-modules" would
> then still be made depending on "kernel-module-foo-<version>" and the likes.
>

Wouldn't this break your primary use case ? i.e. if you had two kernels in
the image or
when you install the 2nd newer kernel, the meta packages would conflict and
hence couldn't
be around at the same time ?

Rather than a meta-package, I think it would be feasible to just have the
generated split
modules RPROVIDE both a PN-<VERSION> and PN. i.e. kernel-module-foo and
kernel-module-foo-<version>
would be RPROVIDED by the packages. I'd still consider this the same
solution as #1, just
with a different implementation, but one that wouldn't generate more
packages and slow
the install/generation phase even more.

I'm not sure what happens if two packages can have a different on-disk name
(i.e. kernel-module-foo-1.2
and kernel-module-foo-1.3) and both RPROVIDE "kernel-module-foo". Only one
would be installed,
but if someone did an apt-get or a smart install of kernel-module-foo ..
chaos may erupt.



>
> 2) Make the version postfix configurable with a
> KERNEL_MODULE_PACKAGE_POSTFIX, exactly like the prefix (which was added
> recently). The default would be an empty postfix, but it could be used to
> achieve this functionality for those who need it.
>
> No. 2 is a very simple change. No. 1 is more uncertain (to me at least).
>

I was discussing this change with a few people in person this morning and
we came up with making this
optional as well (your #2), which would ensure that existing use cases are
not broken, but on the
flip side it makes already complex code more complex and would leave some
paths more tested
than others.

If #1 is feasible, I wonder if a variant of both 1 an 2 are viable ? i.e.
make the generation of the
packages always have a version in the name, but make the generation of a
"versionless" meta
package be optional (or a versionless RPROVIDE). In the default case they'd
be enabled, and no
one would notice that anything had changed but the module-split code would
have a single path.
In a case where multiple kernels are to be installed, you'd have to disable
the versionless package
generation.

I mentioned wildcards above, I'm not sure if anyone else reading this
thread knows if RDEPENDS
can use wildcards ? i.e. if RDEPENDS="kernel-module-foo-4%"  or
"kernel-module-foo-%" worked,
then I could see the version string requirement being less of an issue and
not something that would
require constant bumping as the kernel version changed.

Bruce


>
> /Ola
>
>


-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20170110/dfe2ad84/attachment-0002.html>