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 (?) 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).
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1695): https://lists.openembedded.org/g/openembedded-architecture/message/1695 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]] -=-=-=-=-=-=-=-=-=-=-=-
