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

[Ola Redell]

2017-01-10 15:45 GMT+01:00 Bruce Ashfield <bruce.ashfield at gmail.com>:

>
>
>>
>> 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 ?
>
>
No, it would not break as far as my tests show. I use the meta package
"kernel-modules" today and since it is versioned (not the version string we
are talking about adding here - but regular package version) it all works
fine. apt-get knows about the versions and installs the latest one, with
dependencies, if I don't say anything else. I don't have any problems
having many kernel-modules packages available for installation in my repos
simultaneously. The fine thing with this is that I can perform an "apt-get
dist-upgrade" (or if I'd prefer apt-get upgrade kernel-modules) to install
all new versions of the packages. When I have done that, apt-get finds out
that the older packages are no longer needed and allows me to remove them
(when I want to remove them - i.e. when I know my new kernel works fine)
using "apt-get autoremove". (A note here: After my first kernel upgrade
this is not the case because apt-get considers the original kernel and all
original kernel-modules to not having been installed "automatically", that
is not as dependencies to other packages. But after my second dist-upgrade
the autoremove option allows me to remove unused packages)


> 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.
>
>
That is an interesting alternative and I looked in to that a bit by doing
the necessary hack and testing it out. Your earlier concerns are solved
with this - you can do RDEPENDS_x = "kernel-module-foo" and I can install
that virtual package using "apt-get install kernel-module-foo" as long as I
only have one package providing that virtual package available.  But as
soon as I have more than one package providing that virtual package,
apt-get refuses to install it without me stating exactly what package I
want. Hence I then need to point out kernel-module-foo-<version>. The
reason for this seems to be that virtual packages are not versioned (again
package version - not the postfix string we discuss here). This is not a
huge problem for me with my current use case, but if I'd only install a
couple of kernel modules with bitbake and then later would want to upgrade
them using e.g. "apt-get dist-upgrade" or "apt-get upgrade", that would be
a problem.

I agree adding a huge number of more meta packages should be avoided if
possible.


>
>
>>
>> 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.
>

Given my tests described above, this may be the best solution, yes.


>
> 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.
>

I have not tested this yet and don't know if it would work, but of course
it would require recipes to be changed.

Ola
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20170111/f9880153/attachment-0002.html>