On Tue, Jan 10, 2017 at 3:44 AM, Ola Redell <ola.red...@gmail.com> wrote:
> > > On 01/09/2017 06:20 PM, Bruce Ashfield wrote: > > > The functionality you describe is a good thing, but I have a few questions > to make > sure I understand the change, and confirm that existing functionality > isn't broken .. > and that the internals of the package management do the right thing (I'm > not an > expert on those internals .. so bear with me). > > I am not an expert either so I thought I'd suggest this since it works for > me and see how it is received. > A good plan. It is always better to spur discussion with a tangible patch, which it has done! > > With this change, do you know if RDEPENDS="kernel-module-foo" still works > ? or > does it now have to be RDEPENDS="kernel-module-foo-<version>" ? > > No, the old writing would not work. You would need to add the version as > in your second example. That will break things, true. > ok. That was what I thought as well. As you noted, that is a problem since it would now mean that any recipe that wants to rrecommend or rdepend on a package no longer has kernel version flexibility (unless wildcards are in play) and not the virtual/kernel type binding that it may have had before. > On a similar thought, "smart install kernel-module-foo" would also work ? > or does it > now require a version ? > > Also in this example you would need to add the version, even though I have > only used apt-get and not smart. > > The meta package "kernel-modules" will work as before, without a version > postfix. > As it turns out, I normally use the meta package myself, but I do know of others that don't use it, but do reference individual module packages. > > 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 ? 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. > > 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. 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. Bruce > > /Ola > > -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
-- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
