search

garmin / pyrex

Seamless container setup for developing with OpenEmbedded/Yocto Project
Apache License 2.0
38 stars 30 forks source link

pyrex.ini: Default to 20.04 #61

Closed JoshuaWatt closed 3 years ago

JoshuaWatt commented 3 years ago

Defaults to 20.04 since that is the most recent sanity tested Ubuntu version

matthoosier-garmin commented 3 years ago

Ugh, I don't like this loose lockstep assumption that pervades everywhere through OE.

Can we inspect the branch of OE being used ("bitbake --something-or-other") to make an intelligent decision about what the latest officially supported version of Ubuntu was for the given oe-core release?

JoshuaWatt commented 3 years ago

Ugh, I don't like this loose lockstep assumption that pervades everywhere through OE.

Can we inspect the branch of OE being used ("bitbake --something-or-other") to make an intelligent decision about what the latest officially supported version of Ubuntu was for the given oe-core release?

You could possibly trawl through the SANITY_TESTED_DISTROS, but I don't know how you could do that reasonably without having a valid environment to invoke bitbake in the first place. Ideally, the end users maintain a pyrex.ini that specifically works for the version(s) of upstream they are trying to build.

It's a bit of a catch-22; if we keep the version pined at some older version, it won't work out of the box with the latest upstream. If we move it, it doesn't work with older branches. I don't think there is some reliable way of magically knowing what version to use that is better than the user being explicit about it. The best compromise I can think of is to make it so that mkconfig writes the current version into the user pyrex.ini when they generate it, so it's fixed instead of floating to the latest version when we update it here... but even that isn't the best because it means developers working on upstream master don't get the latest version automatically

JoshuaWatt commented 3 years ago

Also, FWIW it's not really as "lock step" as you might expect; upstream supports multiple versions of Ubuntu, but they will eventually drop 18.04

matthoosier-garmin commented 3 years ago

Ugh, I don't like this loose lockstep assumption that pervades everywhere through OE. Can we inspect the branch of OE being used ("bitbake --something-or-other") to make an intelligent decision about what the latest officially supported version of Ubuntu was for the given oe-core release?

You could possibly trawl through the SANITY_TESTED_DISTROS, but I don't know how you could do that reasonably without having a valid environment to invoke bitbake in the first place. Ideally, the end users maintain a pyrex.ini that specifically works for the version(s) of upstream they are trying to build.

It's a bit of a catch-22; if we keep the version pined at some older version, it won't work out of the box with the latest upstream. If we move it, it doesn't work with older branches. I don't think there is some reliable way of magically knowing what version to use that is better than the user being explicit about it. The best compromise I can think of is to make it so that mkconfig writes the current version into the user pyrex.ini when they generate it, so it's fixed instead of floating to the latest version when we update it here... but even that isn't the best because it means developers working on upstream master don't get the latest version automatically

I was thinking simpler: parse for DISTRO_CODENAME in meta-poky/conf/distro/poky.conf.

And yes, I know that Poky isn't technically guaranteed to be used. Maybe fall back to the latest-and-greatest policy you originally proposed here, for that 1% case?

matthoosier-garmin commented 3 years ago

Also, FWIW it's not really as "lock step" as you might expect; upstream supports multiple versions of Ubuntu, but they will eventually drop 18.04

I meant OE's configuration of having a constellation of branches in every meta-repository that sort of expect to slide together.

JoshuaWatt commented 3 years ago

Ugh, I don't like this loose lockstep assumption that pervades everywhere through OE. Can we inspect the branch of OE being used ("bitbake --something-or-other") to make an intelligent decision about what the latest officially supported version of Ubuntu was for the given oe-core release?

You could possibly trawl through the SANITY_TESTED_DISTROS, but I don't know how you could do that reasonably without having a valid environment to invoke bitbake in the first place. Ideally, the end users maintain a pyrex.ini that specifically works for the version(s) of upstream they are trying to build. It's a bit of a catch-22; if we keep the version pined at some older version, it won't work out of the box with the latest upstream. If we move it, it doesn't work with older branches. I don't think there is some reliable way of magically knowing what version to use that is better than the user being explicit about it. The best compromise I can think of is to make it so that mkconfig writes the current version into the user pyrex.ini when they generate it, so it's fixed instead of floating to the latest version when we update it here... but even that isn't the best because it means developers working on upstream master don't get the latest version automatically

I was thinking simpler: parse for DISTRO_CODENAME in meta-poky/conf/distro/poky.conf.

And yes, I know that Poky isn't technically guaranteed to be used. Maybe fall back to the latest-and-greatest policy you originally proposed here, for that 1% case?

You can do it independently of poky by looking at LAYERSERIES_CORENAMES in meta/conf/layer.conf of oe-core. You could make it so that there is some special token like @autoimage@ in config:image that if present would get expanded to the image that matches one of the corenames (it's a list). However, this is a little more difficult that it might seem at first because pyrex.py is really quite ignorant about the layer layout; most of that is handled in pyrex-init-build-env or capture.sh