<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-01-10 15:45 GMT+01:00 Bruce Ashfield <span dir="ltr"><<a target="_blank" href="mailto:bruce.ashfield@gmail.com">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="gmail-"><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><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><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><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>I agree adding a huge number of more meta packages should be avoided if
possible.<br> <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"></div><div class="gmail_quote"><span class="gmail-"><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><div>Given my tests described above, this may be the best solution, yes. <br> <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"><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><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.<br></div><br></div>Ola<br><br></div></div>