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

Thu Jan 12 13:44:20 UTC 2017

On Wed, Jan 11, 2017 at 9:43 AM, Ola Redell <ola.redell at gmail.com> wrote:

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

Aha. Good to know. I wasn't sure, not having tried this myself.

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

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 agree adding a huge number of more meta packages should be avoided if
> possible.
>

Agreed again. If possible, taking a first step that doesn't break the
existing use cases,
but only adds a minor extra step in your transition case (individual module
installs) is
probably the least controversial route to take.

It would also be something that could evolve once in the tree.

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

Sounds like a plan to me.

>
>
>>
>> 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.
>
>
True, but at least it would be a one time change, which would be preferable
to something that
needed to be bumped each time the kernel version moved.

Cheers,

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/20170112/c370dff8/attachment-0002.html>