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 <
> quentin.schulz@streamunlimited.com> 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.

>
> >
> > > 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.

Quentin