On Thu, Dec 29, 2022 at 5:28 PM Trevor Woerner <[email protected]> wrote:
> On Thu 2022-12-29 @ 03:51:08 PM, Martin Jansa wrote: > > On Thu, Dec 29, 2022 at 3:38 PM Trevor Woerner <[email protected]> > wrote: > > > > > On Thu 2022-12-29 @ 01:56:51 PM, Richard Purdie wrote: > > > > There are variations on this, such as a conditional append on some > > > > override to SRC_URI but the fundamental problem is one of cleanup > when > > > > unpack is to rerun. > > > > > > ...just to elaborate a bit more on this variation for everyone's > benefit > > > (Richard already understands the details of my scenario): > > > > > > Some recipes require us to generate config files by hand in order to > get a > > > piece of software/service to work a correctly in our environment. A > > > concrete > > > example could be specifying the IP address of a time server to use for > > > clock > > > synchronization in chrony's /etc/chrony.conf file. Another example > could > > > be to > > > provide a /etc/network/interfaces file so networking works on a given > > > device > > > in our specific network. > > > > > > In my case I might want to build the same image, for the same device, > but > > > use > > > two different sets of config files. If the device is going to run on my > > > non-routable network then it will use CONDITION1 config files. If I > want to > > > build a set of images for devices running on my routable network then > I'll > > > need to use the CONDITION2 set of config files: > > > > > > meta-project > > > ├── README > > > ├── conf > > > │ └── layer.conf > > > └── recipes-configfiles > > > ├── chrony > > > │ ├── chrony_%.bbappend > > > │ └── files > > > │ ├── condition1 > > > │ │ └── chrony.conf > > > │ └── condition2 > > > │ └── chrony.conf > > > └── init-ifupdown > > > ├── files > > > │ ├── condition1 > > > │ │ └── interfaces > > > │ └── condition2 > > > │ └── interfaces > > > └── init-ifupdown_%.bbappend > > > > > > Then, somewhere, I either specify: > > > > > > MACHINEOVERRIDES .= ":condition1" > > > > > > or: > > > > > > MACHINEOVERRIDES .= ":condition2" > > > > > > NOTE: using "OVERRIDES .= ":conditionX" doesn't work, it has to be a > > > MACHINEOVERRIDES since not all overrides are evaluated for the > > > fetcher > > > in order to save parsing time (is that correct?) > > > > > > If I do a: > > > > > > $ bitbake <recipe> -c cleansstate > > > > > > (perhaps "-c clean" would be enough?) then perform a build, I always > get > > > the > > > correct set of config files in my image. If I don't do a clenastate > between > > > builds in which I change the override, then I simply get the last > config > > > file > > > that's in the WORKDIR. > > > > > > This example is a bit surprising to me. > > > > I understand the case mentioned by Richard that files aren't removed from > > WORKDIR when they are no longer in SRC_URI (happens to me all the time > when > > e.g. renaming a .patch file and then seeing both old and new .patch file > in > > WORKDIR). > > > > But why doesn't fetcher overwrite your chrony.conf and interfaces file > > after MACHINEOVERRIDES is changed? > > I spent a fair amount of time yesterday proving to myself that it wasn't > changing the config file by simply changing the MACHINEOVERRIDES. But it > wouldn't be the first time I was certain something was working a certain > way, > then later couldn't reproduce it. > > > And are you really changing MACHINEOVERRIDES while MACHINE stays the > same? > > I would expect 2 MACHINEs each with own set of MACHINEOVERRIDES and > recipes > > like this being MACHINE_ARCH not TUNE_PKGARCH and then each will have own > > WORKDIR with own set of files. > > If there's a better way, I'd be quite interested in learning it. I'm pretty > sure MACHINEOVERRIDES wasn't designed for this, and probably isn't the > right > way to go about it, but it's a tool that I have and a tool that, in theory, > should do what I want (?) > I was always using MACHINEOVERRIDES to have common override for multiple different MACHINEs (like SOC_FAMILY, MACHINE_CLASS, MACHINE_VARIANT variables various projects use). I guess changing MACHINE_FEATURES or something like that would be slightly better fit for the usecase, but I understand that you wanted to take advantage of MACHINEOVERRIDES being included in: meta/conf/bitbake.conf:FILESOVERRIDES = "${TRANSLATED_TARGET_ARCH}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}" > it has to be a MACHINEOVERRIDES since not all overrides are evaluated for the fetcher > in order to save parsing time (is that correct?) It's partially correct, it's the FILESOVERRIDES which is used to define FILESPATH which is already quite long and all possible locations are tried until the first existing file is found (iterating over even more possible OVERRIDES values would slow it down). There are a couple things I'm doing, and maybe I'm not doing them the right > way. First off, the decision as to which set of config files to use should > be > done by the user at build time. As such I'm tweaking MACHINEOVERRIDES in > conf/local.conf. Maybe that's too late in the parsing process? > > Second, I'm checking the contents of the config file by looking in chrony's > packages-split area. Maybe that's the wrong place? > > Would I have to create multiple machine.conf files? If so, that's not > really > the correct semantics for this use-case either. Creating multiple binary > packages that are just dropped in at the end could work too, but would > also be > cumbersome (assuming the set of config files would have to be tarballed > up). > I was more concerned that if you just manually change MACHINEOVERRIDES in your local.conf, with the same MACHINE name, then chrony package in MACHINE_ARCH package feed will contain chrony.conf for whatever condition as in MACHINEOVERRIDES in local.conf last time chrony recipe was rebuilt - and if you ever try to use packagemanager on target, you'll never know which "version" you will fetch from package feed. With separate MACHINEs machA-routable machA-nonroutable you'll have 2 separate MACHINE_ARCH packagefeeds and "machA" in MACHINEOVERRIDES will allow you to use the same override "machA" for all the things which are common for both, just the chrony.conf and intefaces would be in "machA-routable/machA-nonroutable" directories to get specific version for each. But depends how big the differences really are, because if it's really just 2 such files, then rebuilding MACHINE_ARCH recipes separately might be too big overhead for your usecase. Cheers,
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1696): https://lists.openembedded.org/g/openembedded-architecture/message/1696 Mute This Topic: https://lists.openembedded.org/mt/95936561/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
