Re: [OE-core] [PATCH v9 4/5] wic: move canned *wks files

[Trevor Woerner <twoerner@gmail.com>]

On Sun 2026-04-05 @ 03:16:26 PM, Richard Purdie wrote:
> On Sun, 2026-04-05 at 08:04 -0400, Trevor Woerner wrote:
> > On Sun 2026-04-05 @ 10:17:40 AM, Richard Purdie wrote:
> > > On Sat, 2026-04-04 at 16:38 -0400, Trevor Woerner wrote:
> > > > On Sat 2026-04-04 @ 07:36:05 PM, Richard Purdie wrote:
> > > > > On Sat, 2026-04-04 at 11:46 -0400, Trevor Woerner wrote:
> > > > > > On Sat 2026-04-04 @ 08:27:13 AM, Richard Purdie wrote:
> > > > > > 
> > > > > > I'm only guessing here, but it looks like someone wrote "wic create" to
> > > > > > run two different ways: with the wks file specified with or without the
> > > > > > ".wks" extension.
> > > > > > 
> > > > > > If ".wks" is not given (e.g. "wic create directdisk-gpt ...", which is
> > > > > > what occurs in the oe-selftest tests, i.e. when wic is run independently
> > > > > > without being part of a bitbake build) then wic invokes its own search
> > > > > > algorithm to try to find the wks file using BBLAYERS and script_dir. In
> > > > > > this case the wks file is specified without the ".wks" and no path
> > > > > > information is given on the cmdline. It is up to wic to find the actual
> > > > > > wks file itself.
> > > > > > 
> > > > > > If the ".wks" is included (which is what happens when wic is called as
> > > > > > part of a bitbake build and therefore the image_types_wic.bbclass is
> > > > > > used) then the class adds the ".wks" at the end, and also gives wic the
> > > > > > path to the wks file which it finds using WKS_SEARCH_PATH which is based
> > > > > > on BBPATH and COREBASE.
> > > > > > 
> > > > > > Assuming the persona of someone who wants to use this new, independent
> > > > > > wic tool, and who knows nothing about The Yocto Project or bitbake, I
> > > > > > think having wic look in "magical" places for the wks file would be hard
> > > > > > to understand and surprising. As an independent tool I think the user
> > > > > > should provide the path to the actual wks file (with the ".wks"
> > > > > > extension) and if that file can't be found as specified on the cmdline,
> > > > > > wic should simply fail with an error.
> > > > > > 
> > > > > > As part of making wic an independent tool, I think wic's code to search
> > > > > > for a wks file if the ".wks" is not provided should be removed. This
> > > > > > means that, as part of the transition, I would have to modify each "wic
> > > > > > create" test in oe-core's oe-selftests. I'm fine with that. That could
> > > > > > be done cleanly if I write a little function to find the wks file in
> > > > > > the wic.py oe-selftest itself using the same logic as is used in the
> > > > > > image_types_wic.bbclass.
> > > > > > 
> > > > > > To summarize: in my opinion, wic shouldn't have search logic. From wic's
> > > > > > point of view the wks file should be specified on the cmdline in a way
> > > > > > that wic will find the file the user wants to use (or not find it).
> > > > > > The oe-selftests should be updated to use the same search logic from
> > > > > > the image_types_wic.bbclass so that when it invokes "wic create" it is
> > > > > > providing wic with the path to a wks file that has a ".wks" extension
> > > > > > (which is how bitbake invokes wic) instead of specifying a bare wks file
> > > > > > and hoping wic will find it.
> > > > > > 
> > > > > > I'm happy to add "files/wic" as another location for
> > > > > > image_types_wic.bbclass to search for wks files.
> > > > > 
> > > > > I guess the first question is are we going to take this for wrynose or
> > > > > not? I'm not particularly happy with the files a top level wic
> > > > > directory, I think it needs to be meta/files/wic. To make that work, we
> > > > > need to tweak the search paths in wic and in image_types_wic.bbclass.
> > > > > If we can resolve that issue, we're probably good to move forward with
> > > > > merging.
> > > > > 
> > > > > I agree that the search path logic should be tidied up. Whether you can
> > > > > provide a search path to wic or whether that has to be done in metadata
> > > > > is an open question. I do see your perspective, equally, if you are
> > > > > using wic within OE, having some search knowledge may be ok. I would
> > > > > want to see it basically using files/wic from BBPATH  with everything
> > > > > else removed. There is a question of how you warn users about old
> > > > > paths. This piece is too late for the release though.
> > > > > 
> > > > > So I'd propose we add files/wic to the search path, move the files
> > > > > there and that lets us at least get some of the changes into the
> > > > > release?
> > > > 
> > > > Sounds perfect, thanks!
> > > 
> > > Since we're running out of time and I really don't want to have to
> > > think about this too much more/again, I've:
> > > 
> > > * written a patch to add files/wic as a search path in wic
> > > * written a patch to add files/wic as a search path in the class
> > > * dropped wic and the canned-wks paths in wic
> > > * dropped wic and the canned-wks paths in the class
> > > * converted wic to use BBPATH instead of BBLAYERS
> > > * added a sanity test to detect the old paths and error
> > > * pushed a contrib/rpurdie branch into the wic repo with the patches
> > > 
> > > This is going to mean people have to update layers to use "files/wic"
> > > but we can clearly tell people they need to do it. If we went with
> > > either of the other locations and changed BBLAYERS -> BBPATH, there
> > > could be corner cases we miss in the detection.
> > > 
> > > Autobuilder testing shows this will break a few layers but it is a
> > > clear error which people can easily fix.
> > > 
> > > How does that look to people?
> > 
> > Sounds great to me!
> > 
> > Presumably we will move the contrib/rpurdie branch to master in
> > git.yoctoproject.org/wic and the SRC_URI of the wic recipe in oe-core
> > will need a tweak before making it official?
> 
> I pushed onto a contrib branch so we can make a decision on this.
> Assuming we go ahead, we'd merge the patches to master, the update the
> recipe accordingly.

I've looked at your patches in oe-core master-next as well as in the wic
repository contrib/rpurdie and they all look fine to me. This is a nice
update for wic.

> Cheers,
> 
> Richard