On Wed, Jan 11, 2017 at 9:43 AM, Ola Redell <ola.red...@gmail.com> wrote:
> > > 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) > Aha. Good to know. I wasn't sure, not having tried this myself. > > >> 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. > > Interesting. I think we've probably fallen off the radar of the casual reader that may have more bitbake knowledge to explain why the virtual package (kernel-modules) provides works with the same name and different versions, while a package with the version postfix that rprovides the same name doesn't work with different versions. > I agree adding a huge number of more meta packages should be avoided if > possible. > Agreed again. If possible, taking a first step that doesn't break the existing use cases, but only adds a minor extra step in your transition case (individual module installs) is probably the least controversial route to take. It would also be something that could evolve once in the tree. > > >> >> >>> >>> 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. > Sounds like a plan to me. > > >> >> 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. > > True, but at least it would be a one time change, which would be preferable to something that needed to be bumped each time the kernel version moved. Cheers, 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
