2017-01-10 15:45 GMT+01:00 Bruce Ashfield <bruce.ashfi...@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) > 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. I agree adding a huge number of more meta packages should be avoided if possible. > > >> >> 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. > > 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. Ola
-- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
