<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 10, 2017 at 3:44 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 bgcolor="#FFFFFF" text="#000000"><span class="">
<br>
<br>
<div class="m_1982534508734882033moz-cite-prefix">On 01/09/2017 06:20 PM, Bruce Ashfield
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr"><br>
<div class="gmail_extra">
<div class="gmail_quote">
<div>The functionality you describe is a good thing, but I
have a few questions to make<br>
</div>
<div>sure I understand the change, and confirm that existing
functionality isn't broken .. <br>
</div>
<div>and that the internals of the package management do the
right thing (I'm not an<br>
</div>
<div>expert on those internals .. so bear with me).<br>
</div>
</div>
</div>
</div>
</blockquote></span>
I am not an expert either so I thought I'd suggest this since it
works for me and see how it is received.<span class=""><br></span></div></blockquote><div><br><br></div><div>A good plan. It is always better to spur discussion with a tangible patch, which it has done!<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class="">
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>With this change, do you know if
RDEPENDS="kernel-module-foo" still works ? or<br>
</div>
<div>does it now have to be
RDEPENDS="kernel-module-foo-<<wbr>version>" ?<br>
<br>
</div>
</div>
</div>
</div>
</blockquote></span>
No, the old writing would not work. You would need to add the
version as in your second example. That will break things, true.<span class=""><br></span></div></blockquote><div><br><br></div><div>ok. That was what I thought as well. As you noted, that is a problem since it would now<br></div><div>mean that any recipe that wants to rrecommend or rdepend on a package no longer has<br></div><div>kernel version flexibility (unless wildcards are in play) and not the virtual/kernel type <br></div><div>binding that it may have had before.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class="">
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>On a similar thought, "smart install kernel-module-foo"
would also work ? or does it<br>
</div>
<div>now require a version ?<br>
<br>
</div>
</div>
</div>
</div>
</blockquote></span>
Also in this example you would need to add the version, even though
I have only used apt-get and not smart.<br>
<br>
The meta package "kernel-modules" will work as before, without a
version postfix.<br></div></blockquote><div><br></div><div>As it turns out, I normally use the meta package myself, but I do know of others that <br></div><div>don't use it, but do reference individual module packages. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<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></div><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 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><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 class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<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><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><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%" 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><br></div><div>Bruce<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<br>
/Ola<br>
<br>
</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>