12296 2017-11-02 19:06:04 +0000 standalone wic in "classic" SDK 2025-04-24 14:40:44 +0000 1 1 7 Build System, Metadata & Runtime OE-Core deployment unspecified x86 Multiple ACCEPTED Medium enhancement Future 1 pokylinux twoerner kexin.hao randy.macleod ross.burton tim.orling twoerner --- --- Don't know oldest_to_newest 77935 0 pokylinux 2017-11-02 19:06:04 +0000 I think wic would be great as a default tool not only in the extensible SDK, but also in the "standard" SDK. Unfortunately it does not seem to be a "package", but just a bunch of scripts under /scripts and /scripts/lib/wic. 85536 1 tim.orling 2019-11-14 16:01:35 +0000 This series appears to have been related: https://patchwork.openembedded.org/series/13816/ http://lists.openembedded.org/pipermail/openembedded-core/2018-August/273512.html It doesn't seem to have been merged. 92041 2 randy.macleod 2021-11-18 16:20:16 +0000 Richard Purdie suggested that wic could be managed as an independent package and then used by oe-core but that would require someone to set that up and maintain it... 97320 3 ross.burton 2023-11-23 16:20:26 +0000 Might be a good place to mention that I've vague plans to replace wic with pengutronix's genimage, which can be built into a sdk. 101595 4 twoerner 2025-04-09 15:00:31 +0000 Currently there is a strong coupling between bitbake and wic. In many places, whenever wic wants to know some information it calls bitbake directly via wic/misc.py::get_bitbake_var(). Here is a count of such interactions: $ grep -r get_bitbake_var * | grep "^scripts" | cut -d':' -f1 | uniq -c 6 scripts/wic 1 scripts/lib/wic/help.py 5 scripts/lib/wic/misc.py 3 scripts/lib/wic/engine.py 22 scripts/lib/wic/plugins/source/isoimage-isohybrid.py 2 scripts/lib/wic/plugins/source/rawcopy.py 3 scripts/lib/wic/plugins/source/rootfs.py 4 scripts/lib/wic/plugins/source/bootimg-partition.py 8 scripts/lib/wic/plugins/source/bootimg-pcbios.py 21 scripts/lib/wic/plugins/source/bootimg-efi.py 3 scripts/lib/wic/plugins/imager/direct.py 3 scripts/lib/wic/pluginbase.py 5 scripts/lib/wic/partition.py 3 scripts/lib/wic/ksparser.py This is probably one of the primary reasons why wic can be part of the eSDK, but is not part of the SDK: it needs to have bitbake available to query these variables. In order to make wic a tool that runs independently of bitbake, it will be necessary to: - investigate each of these calls and either remove them or add cmdline arguments as the communication mechanism - remove lib/wic/misc.py::get_bitbake_var() 101599 5 twoerner 2025-04-09 16:20:00 +0000 wic is the front end of a set of related functions. The most well-known of which is "wic create". In addition to "create" wic also includes the following functions: - list [list wks files] - ls [*] - cp [copy files in/out of partitions in image (only vfat and ext supported)] - rm [remove files from partitions in image (only vfat and ext supported)] - write [flash image to device] - help [*] ls has two behaviours: - on the whole image, works like "fdisk -l <image>" - on a partition in the image, does a regular "ls" of a directory - currently only supported for vfat and ext filesystem partitions The vast majority of the coupling between wic and bitbake (via lib/utils.py::get_bitbake_var()) occurs in paths related to "wic create". It is quite easy to remove enough coupling to get many of the other tools decoupled (ls, cp, rm). As a proof of concept I have created a branch demonstrating this: https://web.git.yoctoproject.org/wic/log/?h=no-create By removing the create, list, and write sub-functions, wic is able to stand independently from bitbake and is able to be included in an SDK (for example). 101704 6 twoerner 2025-04-22 14:35:49 +0000 patch added to oe-core https://git.openembedded.org/openembedded-core/commit/?id=1c690aa046ebca13d7b29de50d42b5d8a4a8486c 101706 7 twoerner 2025-04-22 14:38:49 +0000 oops! closed the wrong bug! 101730 8 randy.macleod 2025-04-24 14:40:44 +0000 Closed the wrong bug so reset to accepted state.