Hi Thorsten, If I understand correctly, you're looking for a way to distribute sysexts such that they can be enabled/disabled, and they're updated in lock step with each other and the base OS. Is that correct? If so, you're looking for Optional Features [1], which will release with 257 Best, Adrian <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 31, 2024, 07:16 Thorsten Kukuk <<a href="mailto:kukuk@suse.com">kukuk@suse.com</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi, I'm currently working on integrating systemd-sysext in MicroOS. For this I created several sysext images with different tools (e.g. "gcc", "debug", ...) which I can add in parallel. Which, besides some problems with SELinux and transactional-update, works. Now the idea is to use systemd-sysupdate to update the sysext images, but the implementation is very specific for "there is on OS, which consists of several images, where the ones with the same version belong together". Example output: Determining installed update sets… Determining available update sets… VERSION INSTALLED AVAILABLE ASSESSMENT ↻ 20.2 ✓ candidate ● 20.1 ✓ ✓ current+incomplete 19.1 ✓ installed+incomplete 17.1 ✓ installed+incomplete 16.1 ✓ installed+incomplete 15.2 ✓ installed+incomplete That's not really helpful to see, what is the "gcc" and what is the "debug" image or something else. Are there any plans to support images with different names and version numbers to make this usable with sysext images? I would like to avoid adding image handling to zypper... I'm using systemd from current git. Thanks, Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg) </blockquote></div>