<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 11, 2017 at 9:43 AM, Ola Redell <span dir="ltr"><<a href="mailto:ola.redell@gmail.com" target="_blank">ola.redell@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">2017-01-10 15:45 GMT+01:00 Bruce Ashfield <span dir="ltr"><<a href="mailto:bruce.ashfield@gmail.com" target="_blank">bruce.ashfield@gmail.com</a>></span>:<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div dir="ltr"><span class="m_-2014262970136456767gmail-"><div> </div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div bgcolor="#FFFFFF">
<br>
So basically, as I understand it, this may be a blocker for this
change. Alternatives I can come up with are:<br>
<br>
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.<br></div></blockquote><br></span><div class="gmail_extra"><br><div class="gmail_quote">Wouldn't this break your primary use case ? i.e. if you had two kernels in the image or<br>when you install the 2nd newer kernel, the meta packages would conflict and hence couldn't<br>be around at the same time ?<br><br></div></div></div></blockquote><div><br></div></span><div>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)<br></div></div></div></div></blockquote><div><br><br></div><div>Aha. Good to know. I wasn't sure, not having tried this myself.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><span class=""><div> </div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"></div><div class="gmail_quote">Rather than a meta-package, I think it would be feasible to just have the generated split<br></div><div class="gmail_quote">modules RPROVIDE both a PN-<VERSION> and PN. i.e. kernel-module-foo and kernel-module-foo-<version><br></div><div class="gmail_quote">would be RPROVIDED by the packages. I'd still consider this the same solution as #1, just<br></div><div class="gmail_quote">with a different implementation, but one that wouldn't generate more packages and slow <br></div><div class="gmail_quote">the install/generation phase even more.<br></div></div></div></blockquote><div> <br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><br></div><div class="gmail_quote">I'm not sure what happens if two packages can have a different on-disk name (i.e. kernel-module-foo-1.2<br>and kernel-module-foo-1.3) and both RPROVIDE "kernel-module-foo". Only one would be installed,<br></div><div class="gmail_quote">but if someone did an apt-get or a smart install of kernel-module-foo .. chaos may erupt.<br></div><div class="gmail_quote"></div><div class="gmail_quote"><br></div></div></div></blockquote><div> </div></span><div>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. <br><br></div></div></div></div></blockquote><div><br><br></div><div>Interesting. I think we've probably fallen off the radar of the casual reader that may have<br></div><div>more bitbake knowledge to explain why the virtual package (kernel-modules) provides <br></div><div>works with the same name and different versions, while a package with the version postfix<br></div><div>that rprovides the same name doesn't work with different versions.<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I agree adding a huge number of more meta packages should be avoided if
possible.<br></div></div></div></div></blockquote><div><br></div><div>Agreed again. If possible, taking a first step that doesn't break the existing use cases,<br></div><div>but only adds a minor extra step in your transition case (individual module installs) is<br></div><div>probably the least controversial route to take. <br><br></div><div>It would also be something that could evolve once in the tree.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> <br></div><span class=""><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"></div><div class="gmail_quote"><span class="m_-2014262970136456767gmail-"><div> </div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div bgcolor="#FFFFFF">
<br>
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.<br>
<br>
No. 2 is a very simple change. No. 1 is more uncertain (to me at
least).<br></div></blockquote><div><br></div></span><div>I was discussing this change with a few people in person this morning and we came up with making this<br></div><div>optional as well (your #2), which would ensure that existing use cases are not broken, but on the<br></div><div>flip side it makes already complex code more complex and would leave some paths more tested<br></div><div>than others.<br><br></div><div>If #1 is feasible, I wonder if a variant of both 1 an 2 are viable ? i.e. make the generation of the <br></div><div>packages always have a version in the name, but make the generation of a "versionless" meta<br></div><div>package be optional (or a versionless RPROVIDE). In the default case they'd be enabled, and no<br>one would notice that anything had changed but the module-split code would have a single path. <br>In a case where multiple kernels are to be installed, you'd have to disable the versionless package<br>generation.<br></div></div></div></div></blockquote><div><br></div></span><div>Given my tests described above, this may be the best solution, yes. <br></div></div></div></div></blockquote><div><br></div><div>Sounds like a plan to me.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> <br></div><span class=""><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div><br></div><div>I mentioned wildcards above, I'm not sure if anyone else reading this thread knows if RDEPENDS<br></div><div>can use wildcards ? i.e. if RDEPENDS="kernel-module-foo-4%<wbr>" or "kernel-module-foo-%" worked,<br></div><div>then I could see the version string requirement being less of an issue and not something that would<br></div><div>require constant bumping as the kernel version changed.<br></div></div></div></div></blockquote><div> <br></div></span><div>I have not tested this yet and don't know if it would work, but of course it would require recipes to be changed.<span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888"><br></font></span></div></div></div></blockquote><div><br></div><div>True, but at least it would be a one time change, which would be preferable to something that<br></div><div>needed to be bumped each time the kernel version moved.<br><br></div><div>Cheers,<br><br></div><div>Bruce<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="HOEnZb"><font color="#888888"></font></span></div><span class="HOEnZb"><font color="#888888">Ola<br><br></font></span></div></div>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"</div>
</div></div>