Re: WORKDIR fetcher interaction issue


Trevor Woerner
 

On Thu 2022-12-29 @ 03:51:08 PM, Martin Jansa wrote:
On Thu, Dec 29, 2022 at 3:38 PM Trevor Woerner <twoerner@...> 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).

Join {openembedded-architecture@lists.openembedded.org to automatically receive all group messages.