On Tue, 4 Feb 2020 at 16:15, Quentin Schulz < [email protected]> wrote:
> Hi Ryan, > > On Tue, Feb 04, 2020 at 04:00:01PM +0000, Ryan Harkin wrote: > > Hi Quentin, > > > > Thanks for your reply. > > > > On Tue, 4 Feb 2020 at 08:51, Quentin Schulz < > > [email protected]> wrote: > > > > > Hi Ryan, > > > > > > On Mon, Feb 03, 2020 at 05:34:23PM +0000, Ryan Harkin wrote: > > > > Hello all, > > > > > > > > I'm looking for advice on how to support multiple kernel versions in > my > > > > distro with minimal changes, and minimal disruption to my users. > > > > > > > > Some background: > > > > > > > > I have a legacy Sumo based distro with an image config, and a machine > > > > config, with the machine using a 4.9 kernel. Last year, I upgraded > > > > everything to Warrior, and moved to a 4.19 kernel. > > > > > > > > Some of my users who are migrating from Sumo, wish to keep their 4.9 > > > > kernel. So I'm trying to work out how to handle this in the simplest > way. > > > > > > > > I know that I can add a 4.9 recipes to my Warrior branches, set > > > > PREFERRED_VERSION in my distro.conf. But I don't want to change the > > > default > > > > preferred version globally. And I don't really want users to update > the > > > > distro.conf. Ideally, they should be able to take what I give them > and > > > > "just" build it to get a 4.9 or 4.19 variant. > > > > > > > > > > You can make two machine configuration files. One with > > > PREFERRED_VERSION_virtual/kernel = "4.9%" and the other with 4.19. > > > > > > They pick the correct machine when building, they should expect the > > > correct kernel in output. Only applies to images built for this machine > > > so I guess that's what you're looking for? > > > > > > > Yes, this works. > > > > Trying it showed a few small problems. Eg. I have a package that only > builds > > for the 4.19 kernel, and needs to be excluded for 4.9. That's something I > > can > > handle in the recipes using the machine type, of course. > > > > It depends on what exactly does this recipe represent? A kernel module? > In which case, you can put it in your machine configuration file under > MACHINE_ESSENTIAL_EXTRA_RDEPENDS or RRECOMMENDS and omit it for 4.9. > > We have a way to specify runtime dependencies on specific versions: > > https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#var-RDEPENDS > > I unfortunately have no idea if Yocto supports such a thing in DEPENDS. > > Good tips, thanks again! I'll have a play with it. > > > > > > > > > Ideally, I don't want to *have* to build both kernels and then > create two > > > > images. I expect that will cause confusion and lead to people > flashing > > > the > > > > wrong images. So I'd prefer it to be either/or. Of course, I have to > test > > > > all of this, so I want to be able to build both variants in CI, which > > > makes > > > > editing distro.conf even more unattractive. > > > > > > > > > > Same image (POV of bitbake <image>) but different machines, does that > > > match your requirements? > > > > > > FWIW, you can pass MACHINE= to the command line just before bitbake > > > <image> making it rather obvious which machine they pick. > > > > > > > Incidentally, that didn't work for me, but that's a symptom of how we > setup > > the environment, where local.conf sets MACHINE. I changed it to "MACHINE > ?= > > ", > > thinking it would let me override it via the shell. But it didn't. > Strange, > > but not a > > big problem. > > > > To check who's setting it, run `bitbake <somesimplerecipe> -e | less` and > look > for the line starting with MACHINE=. Then you have the whole bitbake > logic to set it above that line. That could help you find out what's > happening. > Actually, it does work like this: export MACHINE=xyz bitbake image But not like this: MACHINE=xyz bitbake image No big deal, but I expected the last one to work. > Quentin >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#48276): https://lists.yoctoproject.org/g/yocto/message/48276 Mute This Topic: https://lists.yoctoproject.org/mt/70952181/21656 Group Owner: [email protected] Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
